When adding imports for elements, we could leave unnecessary imports because the first element is imported through one library, and then a subsequent element is imported through a library that _also_ includes the first element.
With this change, any time we add a new element import, we will check the existing pending imports to see if any of those can be satisfied by this new import, and if so map it over and check whether the old import is now unused by any element imports (and not an explicit import), in which case it can be removed.
Fixes https://github.com/dart-lang/sdk/issues/56627
Change-Id: I82b638dfd2a36a72e5c7c55cae73842907ea3896
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/384780
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Previously any pending imports added by DartFileEditBuilder would just be sorted by their text ignoring the kind of import. If there were existing imports for dart, package, relative then they might be inserted in the right places, but if there were not (or not the right kind) of existing imports, they would be just be added in alphabetical order (rather than dart, then package, then relative).
This change extracts some of the rules for sorting directives from analysis_server's ImportOrganizer into analyzer_plugin/src so that they can be reused by the DartFileEditBuilder that lives there.
Fixes https://github.com/dart-lang/sdk/issues/56657
Change-Id: I6dc5476add2b7b1804080ffdc8270d0bb80597db
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/384284
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
`DartFileEditBuilder._importLibrary says "If [prefix] is an empty string, adds the import without a prefix", however the handling of an empty string would not match with prefixless imports due to an equality check (null vs empty string).
There was already a correct check further down, so this change moves that check further up and removes the bad condition from the earlier check.
Change-Id: I6a3a38cf9cae23e0d5e07804ef262d515af741f1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/383322
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This is the core implementation of the "plugin server" that will support the API described at https://docs.google.com/document/d/1T8P323DJxsc3YPzveNIaSKWFkrJp9ydTR4jp_XFb7XQ/edit?resourcekey=0-f8Ue29KMUizqXNGhATp1tg#heading=h.23fjh5hfm2is
This is heavily curbed from the ServerPlugin class at
`package:analyzer_plugin/plugin/plugin.dart`, but does not depend on it.
It depends on two concepts from the analyzer_plugin package: (1) the
protocol used for de/serializing requests, responses, etc. And (2) the
`PluginCommunicationChannel` class. This is also just a utility for
communicating between the analysis server and the plugin server.
This plugin server is capable of "registering" individual "plugins",
which allows plugins to register individual (maybe multiple) lint rules,
and individual (maybe multiple) quick fixes.
The plugin server for now only responds essentially to three requests:
* `ANALYSIS_REQUEST_SET_CONTEXT_ROOTS`
* `EDIT_REQUEST_GET_FIXES`
* `PLUGIN_REQUEST_VERSION_CHECK`
All files are analyzed during `handleAnalysisSetContextRoots`, and
quick fixes are calculated during `handleEditGetFixes`.
There are many TODOs, but the included test shows that this plugin
server can notify the analysis server of lint diagnostics to be
reported, and can respond to a query for quick fixes.
Change-Id: Ibc93332319220a2caf49d20ab480940041a15049
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/382480
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Work towards https://github.com/dart-lang/language/issues/2
The feature is well-specified at the issue, but I will also follow
up with a specification to check into the language repo.
This change implements the feature more-or-less from front to back
(because the back is very close to the front in this case :P; no
"backend" work in the VM, etc). Digit separators are made available
via a new experiment, `digit-separators`.
Care is taken to report a single error when an underscore appears in
an unexpected position (see new `separators_error_test.dart`).
Three test files are added:
* `separators_test.dart` is run with the experiment enabled, and has
no compile-time errors.
* `separators_error_test.dart` is run with the experiment enabled, and
has many compile-time errors.
* `separators_error_no_experiment_test.dart` is run with the
experiment _disabled_.
Change-Id: I7f1b1305d28b708b5ddf83f26188cd6e9ce3dd58
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/365181
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
Reviewed-by: Kevin Moore <kevmoo@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
In this CL, I do not change the signature of any EditBuilder code, as
it is public analyzer_plugin API. I only change doc comments and a few
impl nits here and there, to make more modern or idiomatic.
This CL is isolated this way so that when I do a copy to the
analysis_server_plugin package, the moves will be smaller, readable
diffs (almost zero diff, just imports and things like that).
Change-Id: Ibc8a5ddb9a679278dd7223a3e2d868fe21c4acef
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/363881
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Fixes https://github.com/dart-lang/sdk/issues/54247
The main piece of this CL is a rewrite of the `ignoredElements`
extension on CommentToken. This was a private extension getter, but
is made public now for two reasons: first is to reference it in tests,
and second is to make it available for a new lint rule in an upcoming
CL.
The new implementation drops all use of RegExp in order to more
precisely track when we may be at the end of a list of diagnostic
names and/or types. So the functional change here is that a diagnostic
name or type followed by whitespace instead of a comma marks the end
of the list. Any characters following that whitespace are not parsed,
as they are considered freeform comment text. While the new
implementation parses a comment code-unit-by-code-unit, it is still
a rather concise impl.
* Rename DiagnosticName and DiagnosticType to IgnoredDiagnosticName
and IgnoredDiagnosticType; these names make more sense to me,
specifically when they are used outside of the ignore_info.dart
file.
* I introduce a new test file, ignore_info_test, to capture these
various parsing particulars, that aren't specifically concerned with
matching an ignore comment with a diagnostic. A few test cases from
ErrorSuppressionTest are moved over here.
* A number of String (well, int, technically) helper functions are
moved to analyzer, along with their tests.
Fixes https://github.com/dart-lang/sdk/issues/54247
Change-Id: Ife08d448a4e03b8a55b183d88a3ea8d07812fbdc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/363820
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Fixes https://github.com/dart-lang/sdk/issues/55264
Fields added to enums are final.
Also:
* Fix a bug in CreateField - fields created from function-typed field
formal parameters now have the right type.
* Fix a "bug" in CreateField - fields created from a field formal
parameter in a const constructor are now final.
* Add more tests for CreateField.
Change-Id: I7d1344f6214c89e6351d3b5ed18b71ac97b9a310
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/362420
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
In the *Builder APIs, this is what has changed:
* Add a parameter to `writeOverride` called `setSelection` which
controls whether selection should be set.
* `_addCompilationUnitMemberInsertion` is made public as
`insertIntoUnitMember`. Callers can insert multiple things into a
unit member, so it's a pretty generic name.
* Improved handling of synthetic brackets for all existing add*
APIs, like `class A extends B`. Many fixes and refactorings will
now write brackets if necessary.
Change-Id: I7ed79793c8625ec922ab8de2cb9e6fc33d022b76
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/362183
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Add `DartFileEditBuilder.addConstructorInsertion`, a replacement for
both `CorrectionUtils.prepareEnumNewConstructorLocation` and
`CorrectionUtils.prepareNewConstructorLocation`. Combining the two
APIs is made possible by adding enum support to _InsertionPreparer.
For example, constructors can be inserted after an enum value-list's
semicolon (if there is one), or after the last value (if there isn't).
Also:
* Refactor _InsertionPreparer a bit to be cleaner; in the constructor,
we determine whether we can grab the `NamedCompilationUnitMember`
members.
* Instead of storing a `_targetMember` as a field, which is only null-
checked, store a Boolean value for whether a target member was
found.
* Remove pre-nnbd support in `DartFileEditBuilder.writeParameter`.
Change-Id: I3e98ed906cf5ac82e464c502db5986d3761c3611
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/361624
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
I renamed a few classes, then sorted them, so the diff is big.
Broadly, here is a summary of the code before: two "ignore diagnostic"
correction producers were in place, and the one that inserts a
"ignore_for_file" comment (IgnoreDiagnosticInFile) uses a
`CorrectionUtils.getInsertionLocationIgnoreForFile` function to get an
InsertionLocation object, then passes that to `_computeEdit()`, a
method defined in a parent class. `_computeEdit()` takes that
InsertionLocation object, and uses LineInfo, to determine whether we
need to _append_ to an existing ignore-comment (in which case all
other InsertionLocation information is discarded), or write a full
comment, and use the InsertionLocation prefix and suffix.
To me this was a pretty complicated set-up: IgnoreDiagnosticInFile
calls out to a function defined in a separate library to do "the first
half" of the location calculation. Then the `_computeEdit()` function
has to finish the job, which might involve ignoring computations done
in the first half.
I've changed it to instead be the following design: Each class,
IgnoreDiagnosticInFile and IgnoreDiagnosticOnLine, wholly implements
`compute()` (removing the parent `_computeEdit()` method). The former
class has the much bigger task of finding an appropriate position near
the top of the file in which it can insert a comment. Instead of
tracking a lot of variables along the way, this code quickly calls out
to `insertAt()` as soon as it knows where it is inserting, whether it is
appending, and whether we need a newline before the comment, or after.
So everything about the offset, possible prefix, suffix, and decision
to-append is done in one place. The latter class,
IgnoreDiagnosticOnLine, has a much simpler `compute()`, the most
complex part is determining whether to append to an existing comment.
There is not much duplicated. The `insertAt()` method is defined in
the parent class; it is nice to have a method that is agnostic to the
ignore comment being inserted; it just calculates an indent, and
writes the comment.
Summary of changes:
* AbstractIgnoreDiagnostic, the parent of the two mentioned classes,
and IgnoreDiagnosticInAnalysisOptionsFile, is actually a base class,
shouldn't be public, and it's `_computeEdit()` was not relevant for
the 3rd subclass. So I rename it to _BaseIgnoreDiagnostic, and add a
new small class in between: _DartIgnoreDiagnostic. The new class
defines `insertAt()` (only relevant for Dart files), and requires
that subclasses define their `ignorePrefix`.
* `_isCodeUnignorable` is changed from a method to a getter.
* `DartEditBuilderImpl._linePrefix` is moved to an extension on ResolvedUnitResult, along with some helpers. It is moved to `src/` so
not technically part of public API. It should be moved to
server_plugin soon.
* `getInsertionLocationIgnoreForFile` and `getLinePrefix` are removed.
Change-Id: I4757ea2d8a3b43eeec0c8895c5c1fb3edc3ca8a3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/361006
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
`addMethodInsert` and `addCaseClauseAtEndInsert` are only used by code
which combines them with DartEditBuilder, so the change is pretty
simple. A few utilities are needed in DartEditBuilder, which are also
not complicated, such as a utility for getting the existing indentation
string on a line. Using this utility in the shared code should improve
someo of the existing fixes and assists, which didn't use it before.
The same goes for looking at whether left and right brackets are
synthetic. So this change comes with a few minor improvements.
Change-Id: I5b235021ac234b4a50b09dca6d14a28b3f163e5e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/360980
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Primarily this moves `prepareNewFieldLocation` and
`prepareNewGetterLocation` to DartFileEditBuilder, as
`addFieldInsertion` and `addGetterInsertion`. Where
`prepareNewFieldLocation` was previously used in conjunction with
`addInsertion`, a correction producer now just needs to call
`addFieldInsertion`. This new method determines the insertion offset,
and and prefix String and suffix String (just newlines and indents),
and handles the prefix and suffix, surrounding use of the `buildEdit`
callback.
These form a nice new API for correction producers like create_field,
create_getter, and create_setter.
The implementation is a little hairy; the DartFileEditBuilder does not
have access to things like `eol` and `getIndent`; those are made
available in DartEditBuilder, so it does that work in
`addCompilationUnitMemberInsertion`, _inside_ the call to
`addInsertion`, where that builder is available.
Though the implementation is a bit hairy, I think it is a much tidier
API for correction producers. The prior API was a little awkward in
that a correction producer would have to ask CorrectionUtils for this
odd data object that contained an offset, and a prefix and suffix
String. Rather than using these objects in any meaningful way, the
correction producer just gave it back to one or another builder. It
felt opaque to me.
The rest of the `CorrectionUtils.prepare*` methods will follow.
Change-Id: I32f23336c873cee4158a4ac6797961a40d86c25a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/360302
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This was the only caller, and it always passed in `true` for `first`.
Inlining the function is the same number of lines as calling the function and using it's output.
Change-Id: Ifee204e68f2b7d168fe6078ac7f8ec66261ff76b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/360080
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
The analyzer team has decided to adopt the convention of using `TODO`
comments to document long term issues that should persist in the
codebase, and `FIXME` comments to document short term issues that need
immediate attention. They may even consider adding a presubmit hook
to ensure that `FIXME` comments are only used during local
development.
Accordingly, it makes sense to suppress `TODO` comments from being
surfaced to the IDE "problems" view (since there are hundreds of them,
and they're not immediately actionable). This makes VSCode's
"problems" view much more usable in "tree" mode.
(See also https://dart-review.googlesource.com/c/sdk/+/295662, which
made the corresponding change to the `analysis_server` and `analyzer`
packages, and https://dart-review.googlesource.com/c/sdk/+/325121,
which made the corresponding change to the `linter` package).
Change-Id: Ifbd2f6bed468408b1906b25ab94f745eed0b3e55
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/358980
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Previously, we only had descriptions of changes on a SourceChange. In order to support annotated edits over LSP for "Fix All in Workspace" we need to be able to track descriptions on each change within a file so that if we're fixing multiple different lints with a single SourceFileEdit they can be annotated/grouped in the UI.
In order to avoid every fix providing a description, ChangeBuilder has a field that allows recording the current change description and all builders created from it will use that description when creating their changes. This allows the BulkFixProcessor to set the description on behalf of each fix producer ensuring they all get descriptions (which is done in a follow-up CL along with Fix All in Workspace functionality).
Change-Id: Ie1c508056898bd4000a5505cf59a1e6d35d28da0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/356160
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Konstantin Shcheglov