There are no semantic changes in this CL, just renames.
The one unfortunate rename was from `DEFAULT` to `default_`. It can't be
`default` because that's a built-in identifier. If you have a better
convention to follow here I'm happy to change it.
Change-Id: Idf70621ad577dbea6c1c161aac17e9e200aac2d0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/433440
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
The bullets on this doc were bugging me because they were confusing which tasks were subtasks of one another. I made them all into checklist bullets (since that's what's most useful for me anyways) and it looks much better.
Change-Id: I593ceb7db5ae39ffda52a2a2e481b1c53a5a7784
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/433360
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
The related issue asked for a new priority for the `Create class` fix
that would be lower if the undefined name was lowercase, giving the
`Create method` and `Create function` fixes a higher relative priority.
This change also adds a new abstract class to test the relative priority
between fix kinds. It is also used to test agains the merge combinators
fixes.
Fixes: https://github.com/dart-lang/sdk/issues/60523
Change-Id: I938f52a577ecf1b6bb8dd66c94fd45395a011ffa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/422321
Auto-Submit: Felipe Morschel <git@fmorschel.dev>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
This disables the assist if the field formal parameter happens to also
be an older style function typed parameter. As written the assist
produces invalid code, and the older style is strongly discouraged so
not supporting it shouldn't impact very many users.
Change-Id: I44a3942b4656265bb1cbbba29e68fff61962b689
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/433260
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Work towards https://github.com/dart-lang/sdk/issues/60635
I tried to keep this minimal but still sensible:
* Rename AnalysisErrorListener and all subtypes to use 'Diagnostic'.
* Rename all instantiations of such classes if they previously
contained the word 'error'.
* Rename `RecordingDiagnosticListener.errors` to `.diagnostics`.
* Rename some _testing_ instance members that had the word 'error'
to instead use 'diagnostic'.
Change-Id: I3948e27ba28ac2494092e04f4e1d201a20cc1135
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/433004
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This prevents inline values showing up alongside code that didn't execute in conditional blocks. It does also mean they don't know up in conditional blocks that _did_ execute one execution has fallen out of them, but I believe this is the best we can do with the current LSP APIs (unless we try to track execution across requests, but that would probably be complete and not entirely reliable).
Fixes https://github.com/Dart-Code/Dart-Code/issues/5454
Change-Id: Ia1cf2437b76844ff0a6aeeb958d769c9523dc5dd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/433200
Commit-Queue: Keerti Parthasarathy <keertip@google.com>
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This is a partial revert of ca9523058e (it removes the behaviour change and the test that verifies this, but leaves two additional tests that were added relating to roots that are created later).
If we rebuild contexts when a root is deleted, we may get stuck in a loop because we will again try to recreate the same (deleted) root, and then the watcher will close in a way that looks like a deleted folder, and we will repeat.
Fixes https://github.com/dart-lang/sdk/issues/60863
Change-Id: I10289160b341d273e8e409184a1c013c7fb9439d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/433140
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
For https://github.com/Dart-Code/Dart-Code/issues/4729 we added a configuration setting to let you control how much documentation was included in responses. The motivation here was to reduce the completion payload sizes when running in remote workspaces (Dart-Code would adjust the default setting if not explicitly set by the user based on the workspace kind).
However in hindsight, forcing no docs on Hovers just because we didn't want them in Completion requests was a bad choice, because these are individual requests where the payload size is less important and seeing the docs is useful.
So this alters the setting to accept a `Map` to allow you to have different preferences for each request that returns docs. Dart-Code will be updated to adjust the defaults accordingly (after this lands) so that Hover/SignatureHelp can default to `"full"` even in remote workspaces.
Work towards https://github.com/Dart-Code/Dart-Code/issues/5499
Change-Id: Ib64f762a0559c7afc7653fad9749fc208beee8b3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/431280
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
This is a big CL; no code is really "changed." We basically move 3
components into the public API, which can all be reviewed concisely
in the `api.txt` file.
* The AnalysisRule classes: `AbstractAnalysisRule` (which is good to
make public as a lot of the public API is specified and documented
here), `AnalysisRule`, `MultiAnalysisRule`.
* The Pubspec classes, available for linting pubspec files:
`PubspecDependency`, `PubspecDependencyList`, `PubspecEntry`,
`PubspecEnvironment`, `PubspecGitRepo`, `PubspecHost`, `PubspecNode`,
`PubspecNodeList`, `PubspecVisitor`.
* The `RuleVisitorRegistry` class. This class is needed by analysis
rule authors, and is part of the public API of AnalysisRule.
Change-Id: Ib1803180de9469f4ff39cf1778f96787f5f74b14
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/432363
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
This changed definition is required for google3, in order to support
using `WorkspacePackage.isInTestDirectory` over the `inTestDir`
extension getter.
Then remove linter's export of the `inTestDir` extension method, and
instead rely on WorkspacePackage in lint rules.
Change-Id: I81fc6a27ca8f19f71a8b915edb3968d5d43262ac
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/431943
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
I moved several classes out of `diagnostics.dart` into their own
libraries under `pages`. I also moved one of the singling files into
`pages`. Several other sibling pages were moved to `utilities`. In the
process I needed to make a couple of methods public rather than private.
There are no functional changes.
I was going to split out the rest of the classes from `diagnostics.dart`
and `pages.dart` but I haven't yet decided whether they should all go
into a single directory or whether they should be in two directories.
The classes in `pages.dart` appear to be classes appropriate for any
web site generating code while those in `diagnostics.dart` are specific
to this web site, but it isn't clear to me that the abstraction is
helpful given that we only have one web site to build.
Change-Id: Iff968bc3bfb654db24e896cb1ae0ced9bc6333fd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/432360
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This normalizes the names of the classes to match the label displayed to
the user (to make it easier to find the class that needs to be updated).
It also normalizes capitalization in titles and the formation of the
page ids.
This is a precursor to splitting the page classes out into separate files.
Change-Id: I571bfaf23057f2366274e4b853412c8756151f65
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/432121
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This adds a new page to the diagnostic pages that displays the current
state of the message scheduler (or rather the messages passing through
the scheduler) as well as the most recent history.
The next steps after this are to
- include this information (and library cycle information) in the
generated report
- add this (and cycle) information to the analytics we're gathering
I put the new page in its own file, and would like to move existing
pages to separate files as well. Doing so might trigger moving some
files around in the directory structure in order to better organize
the code.
Change-Id: Ic4f0e72ffbadc1e39702f1f8f13850f5bd5814a5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/431947
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
For the analyzer plugin APIs, these classes should not have the word
'Lint' in them, as they are used for all analysis rules, whether they
report lints or warnings.
* LinterContext -> RuleContext
* LinterContextWithParsedResults -> RuleContextWithParsedResults
* LinterContextWithResolvedResults -> RuleContextWithResolvedResults
* LintRuleUnitContext -> RuleUnitContext
I'm open to better names for these. Some of these suffer from a
chain-of-nouns name (a "RuleUnitContext" is a Context for a Unit for
a Rule). So we could go with "UnitContextForRule" and "ContextForRule"
or other ideas like that.
Only RuleContext and RuleUnitContext will be public API.
Change-Id: I5550736beaba7e39b36e7b5584ca6d023aa4d02b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/431703
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Sam Rawlins