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>
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>
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>
This change shouldn't change any current behaviour, but means all "FilePath" types in the legacy protocol spec will go through a (currently no-op) conversion. The server will be able to replace this conversion based on client capabilities in a future CL.
Because a lot of the generated classes are in analyzer_plugin, this also moves the ClientUriConverter class there.
`pkg\analysis_server\test\src\utilities\json_test.dart` contains tests that the toJson/fromJson methods go through the converter recursively (inc. map keys/values/etc.).
Change-Id: If5aec884070128eea594540fd25a9017ada86079
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/349060
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This turns on the flags for these two language features and makes
them generally accessible.
Doing so causes a number of tests to fail, but the failures are
approved and there are filed issues for them. Most of the
failures are minor or only affect code using the new language
features.
This CL:
- Enables the features in experimental_features.yaml.
- Re-generates all of the various files generated from that.
- Makes some analyzer and front end changes that this CL
inherited from Paul's original CL flipping all of the 3.0
feature flags. I don't know what these changes are about, but
I assume they are necessary.
- Pins a couple of tests to 2.19 since they deliberately test
behavior that is specific to 2.19. (For most test changes, I've
landed them separately, but there are a couple of stragglers
in this CL.)
This doesn't enable "class-modifiers" or "sealed-types" and doesn't
include the core lib changes related to those.
TEST=On bots
Change-Id: Id387753772286a958e20a3589a6e983995f2e4a6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/286344
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Jake Macdonald <jakemac@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This shares a cache for mapping Elements to their public LibraryElements across each snippet producer, and also skips snippet producers that produce snippets that won't match any typed prefix.
Change-Id: I6b64b3c55f1030a5eaa7ca1afdcd6c416e4baa08
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/273962
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This fixes a few minor issues:
- Setting a new selection position did not remove a previously set selection range (which could result in a mismatched offset/length due to how the resulting change merges the position/range)
- Setting a new selection range did not update a previously set selection position
- Inserting new changes before a change that sets a selection range only updated the selection position, not selection range
- Setting a selection range/position after another change that inserts only updated the selection position to compensate and not the selection range
These issues led to cases where selection ranges could be incorrect, or even overlap with linked edit groups that could cause errors that caused code action requests to fail.
Fixes https://github.com/Dart-Code/Dart-Code/issues/4184
Change-Id: I43e2a8361c97b2eccb2d6b426a75eda5cc811e06
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/261682
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
pq