NOTE: Amost all of this code was written by AI, but has all been
reviewed by me. I did a tiny amount of cleanup that was faster to do
myself than to ask the agent to do it. That doesn't mean that I've
caught all of the AI's bugs, but I did try to ensure that test coverage
was complete enough to also catch problems.
This fixes a bug in the way the `ChangeBuilder` handled linked edit
groups. The bug resulted from the fact that the offsets of the linked
edit groups was adjusted at the time each edit location was added.
Doing that meant that they weren't re-adjusted when new non-group edits
were added at a lower offset, making it possible for the edits to have
the wrong offsets when they were sent to the client.
The solution is to not adjust them when they are created, but to
adjust them during `finalize` when other offsets are adjusted. At that
point we have full knowledge of all of the edits so we can get it right.
Doing that required adding a reference to the each edit in the file
edit builder (because only the edits in the same file can require that
an adjustment be made).
My hope is that with this change in place I can complete the arc of
work to update all of our refactors to use the `ChangeBuilder` APIs to
build the edits.
Change-Id: I59ddb0dee1f9dbb15bdcc38a84ddc07acefe6262
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/507622
Reviewed-by: Samuel Rawlins <srawlins@google.com>
These files had comments indicating that running
`pkg/analysis_server/tool/spec/generate_files` would regenerate them,
but that was not the case.
Change-Id: I6ceb6352edf6eab5e746276a0a2f33b16a6a6964
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/507521
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Work towards https://github.com/dart-lang/sdk/issues/62686
`dart analyze` uses an 'analysis.setAnalysisRoots' "command" to let
the analysis server know that the user requested, for example,
`dart analyze foo` or `dart analyze foo/bar.dart`. This was not conveyed
to analyzer plugins, so analyzer plugins will always analyze the entire
context collection.
(For some reason, only files in the "analysis roots" were reported in
stdout; maybe DAS or dartdev does its own filtering on diagnostics.)
This change forwards the `setAnalysisRoots` request to DAS plugins using
a new protocol message that mirrors the one for the server.
We should not change the behavior of `analysis.setContextRoots` for
legacy plugins, so we keep sending that request as per usual. Then
we send `analysis.setAnalysisRoots` at the same time.
If we receive an `analysis.setAnalysisRoots` message, dispose and
delete references to the existing context collection, and instantiate
a new one, with the specified `included` and `excluded` paths.
Change-Id: I53627da1c30351a22b5e5410a557bf486620a7aa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/505041
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This prevents a null exception that could otherwise occur during code
completion. I think that this only impacts internal users.
It's not ideal. As you can see from the tests OpType is deciding that
we should be suggesting type names in places where they can't exist,
but I think that's a theoretic issue because I believe that the code
completion code won't access the OpType in these situations.
If I'm wrong, then the failure mode will be to suggest type names
that shouldn't be suggested in a couple of situations. If users do
notice this behavior it should be relatively easy to tighted up the
computation to only suggest the valid completions.
Change-Id: I6ceb9615384371f9dcc4fd30d914c7574ed6e304
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/506340
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Extension type augmentations do not have representation declarations, so
an `ExtensionTypeDeclaration` can no longer always expose its name
through a primary constructor. Add `ExtensionTypeDeclaration.namePart`
as the canonical API for the declared name and type parameters, and keep
`primaryConstructor` as a deprecated compatibility API for introductory
declarations.
Report `extensionTypeAugmentationHasRepresentation` when an augmentation
writes representation syntax. This keeps the parser recovery explicit:
the augmentation still gets a plain `namePart`, while the invalid
representation is diagnosed instead of being modeled as the
declaration's primary constructor.
Synthesize recovery representation and primary constructor fragments
only for the element model when an extension type has no introductory
declaration.
Migrate analyzer, analysis server, analyzer plugin, and linter clients
to read extension type names and type parameters from `namePart`.
Change-Id: I59dd957ac38f087c861b993caf246986dcdac713
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/505067
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
(Part of https://github.com/dart-lang/sdk/issues/63288)
Updates the `CodeGenerator` mixin so that it outputs `ignore_for_file`
comments to ignore the following lints:
- unnecessary_type_name_in_constructor
- unnecessary_ignore
- duplicate_ignore
This mixin is used by the code generators that produce the Dart
wrappers for the analysis server and analyzer plugin wire protocols.
This is a first step towards migrating the packages `analysis_server`,
`analysis_server_client`, and `analyzer_plugin` packages to use the
new constructor declaration syntax, since it will allow the
`unnecessary_type_name_in_constructor` lint to be enabled without
breaking generated code.
Once all the packages have had their SDK constraints bumped to a
language version that supports the new syntax, I'll update the code
generator to use the new syntax, and remove the ignores.
For more information about the new constructor declaration syntax, see
https://github.com/dart-lang/language/blob/main/accepted/future-releases/primary-constructors/feature-specification.md#abbreviations-of-in-body-constructor-declarations.
Change-Id: Ied17e3ea772546675aad48efc324f6f16a6a6964
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/505521
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Avoid constructing file URIs and paths directly from the host platform
when analyzer code is operating on an injected ResourceProvider. Those
direct conversions use the process path context, which is wrong when the
provider is using a Windows path context on another host platform.
Route file URI conversions through ResourceProvider, FileSource, File,
and PathContext APIs instead. This keeps file names, document links,
analysis options includes, navigation targets, and relative paths
aligned with the active provider.
Update affected tests and shared test utilities to use provider-backed
URIs and paths, so they exercise the same path semantics as production
code.
Change-Id: Iaf7751d028273a5fa72a04d8ca60e51aee700594
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/499481
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This fixes a bug that I found while trying to use the ChangeBuilder. It
also fixes a different bug that I found while testing the first. Both
resulted in the ChangeBuilder producing linked edit groups with the
wrong offset.
I found a third bug and I added a comment to identify it, but I'm not
including a fix for it. It doesn't appear to be impacting users at this
point.
While I was in the code, I removed several assertions using `isNotNull`
that can never fire because the actual value's type is non-nullable.
Change-Id: Ic76994339f5eef40316c6f0abc177275588f3996
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/498680
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This CL is a bit different from many previous CLs in a couple of ways.
The smallest difference is that I realized that some of the logic could
be shared and that we have a utility method that just need to be
enhanced a bit to support primary constructors. At some point we should
go back to the previous implementations and update them to use the
utility method.
The larger difference is the use of a pair of wrapper classes to
encapsulate some of the differences between primary and secondary
constructors. I'm not sure how I feel about the two approaches. On the
one hand, the wrapper classes feel a bit heavy-handed, but on the other
hand they could make a lot of code more DRY.
Your thoughts would be appreciated.
Closes https://github.com/dart-lang/sdk/issues/63047
Change-Id: I93af6d2a529bbc0491cf64ff03f7a58e6b874d81
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/495461
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
This avoids a second Map access for retrieving every value in every
message from a plugin.
This also extracts out the `if (json is Map)` case outside of a block,
by short-circuiting when `json` is not a Map.
Change-Id: I962511d44ea797a0105901510a9182b5811b0230
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/487080
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Add `ClassBody.members` and `EnumBody.constants`/`members` so callers
can access class and enum contents through the common body interfaces
instead of pattern matching on `BlockClassBody` and `BlockEnumBody`.
Implement empty node lists for empty class and enum bodies, update the
public API, and migrate analyzer, analysis_server, analyzer_plugin, and
linter code to use the new accessors directly. This removes the ad hoc
`members2` helper extensions and a large amount of repeated `tryCast`
and `switch` logic, making body traversal more uniform.
Change-Id: I51d75f2253c7e6f75efecae84bf0443ff5eb6788
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/488263
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Work towards https://github.com/dart-lang/sdk/issues/61868
This adds a new notification type, 'PluginPrint'. There are several
fields and variables then named 'pluginPrint' or 'print', and I am
definitely open to changing these names, but this is the best one that
I thought of.
PluginPrint has three fields: The name of the plugin that printed, the
message that was printed, and the timestamp.
We wrap each plugin's AnalysisRule invocations with a zone, so that
the `print` handler can know the name of the plugin. The prints are
caught and sent to the server isolate as Notifications. The
PluginIsolate then stores the collected prints. The Plugins Insights
page can then retrieve them and display them.
Manual testing, with 1000 libraries that get new lint reported once per
file, I did not observe a negative performance impact.
Change-Id: Id800ae41781c15ce89d06b563878c2b0edae43d3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/486827
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
This allows the formatter to be both ahead or behind the SDK version and still format correctly. We should not use a newer language version than the SDK is using, and we cannot use a newer version than the formatter supports.
Change-Id: I5ef27363d213f570b2eb0d3b428752aef8e76af1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/487580
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Kallen Tu <kallentu@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This passes any experiments that are both enabled, and marked as "future" through to the formatter.
I extracted most uses of the formatter to use the same shared `createFormatter()` helper that sets the appropriate values. Those that didn't already have a Result to pass I added TODOs to (though one is g3 so probably would require some internal migration).
See https://github.com/dart-lang/sdk/issues/55125
Change-Id: I8f4ef4242614dc240e217cdaf99105f2a5b49dc9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/486840
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Modify the AST rewriting phase to transform `SimpleIdentifier` and
`PrefixedIdentifier` nodes into `TypeLiteral` nodes when they resolve to
a type (such as classes, type aliases, `dynamic`, or `Never`) and appear
within a value expression slot.
This change ensures a more consistent AST representation where type
references used as values are distinct from other identifiers.
Key changes include:
- Generating `isInValueExpressionSlot` methods for AST nodes to identify
valid contexts for type literals.
- Updating `AstRewriteVisitor` to perform the conversion.
- Adjusting constant evaluation, completion, and linter rules to support
`TypeLiteral` nodes in expression contexts.
- Adding comprehensive resolution tests for type literals in assignments,
conditionals, loops, and other structures.
Change-Id: I248481dc9c940dfc0cbea4950b918d2e0a3d9bb6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/479780
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Changes the logic in `pkg/analyzer_plugin` to use
`DiagnosticCode.lowerCaseName` instead of `DiagnosticCode.name`. This
ensures that diagnostic codes are matched in a case-insensitive
fashion.
This paves the way for deprecating (and eventually removing) the
`DiagnosticCode.name` getter.
Change-Id: I6a6a6964db7910a1226693ab60305b25aa02dce5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/466130
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Introduce explicit origin flags on ConstructorElement and its fragment
(isOriginDeclaration, isOriginImplicitDefault, isOriginMixinApplication)
and deprecate isSynthetic in favor of these. Define isSynthetic as the
inverse of isOriginDeclaration to preserve the legacy meaning while
encouraging clients to use the more precise origin predicates.
Eventually `Element.isSynthetic` also will be deprecated and removed.
This CL is a step toward this goal, migrating what is possible with new
flags.
Update analyzer internals to rely on the new origin flags when checking
for non-factory generative constructors, building synthetic constructors
for mixin applications, and walking constructor chains in index/search
logic. Only constructors with an origin declaration are now treated as
declarations, and nonSynthetic is defined in terms of origin
declarations rather than synthetic-ness. Add corresponding origin
descriptors to the manifest enum and bump AnalysisDriver.DATA_VERSION.
Adjust analysis server refactorings and fixes to distinguish implicit
default constructors from other synthetic constructors. Code paths that
previously checked isSynthetic for default constructors now check
isOriginImplicitDefault, and mixin-application traversal uses
isOriginMixinApplication.
Overall, this change removes the overloaded semantics of isSynthetic,
makes constructor provenance explicit, and prepares the element model
for future DeCo and primary-constructor scenarios without relying on
brittle synthetic heuristics.
Change-Id: I8568bdfe478867af313a4d13afe1f2859394831b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/465201
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Konstantin Shcheglov