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>
(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>
Move the analyzer-only Diagnostic, DiagnosticMessage, Severity, and
locatable diagnostic helper types out of _fe_analyzer_shared and into
package:analyzer.
I paln to make changes outlined in
https://github.com/dart-lang/sdk/issues/63311 and chat discussion.
Keeping these classes in the analyzer simplifies the migration and
avoids introducing a shared abstraction before there is a concrete need
for one.
If we decide later need to have a shared abstraction, we can always
extract one at that point. With coding agents internal code motion is
cheap.
Update analyzer, analysis server plugin, analyzer plugin, linter, and
scanner call sites to import the moved APIs from analyzer libraries, and
refresh API baselines to reflect the new public owner.
Change-Id: Ie0ef0f01c6e4be7ebaac25619ac3e3fe991a44d9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/501000
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Move PackageConfigFileBuilder into the analyzer_testing public API and
deprecate the copy exposed from package:analyzer. The builder is only
used by test infrastructure, so keeping it in analyzer_testing makes the
ownership clearer and avoids exposing test-only utilities from analyzer.
Update the builder API to accept a rootFolder instead of a rootPath.
This lets callers pass the resource-provider folder directly, so the
generated rootUri is derived from the same file-system abstraction that
created the test files. This avoids accidentally passing POSIX paths
where resource provider paths are required, such as on Windows.
Update existing test utilities and callers to import the new library and
pass Folder objects. Remove the production analysis server dependency on
the builder by emitting the temporary plugin package config JSON
directly.
Change-Id: I46b14710626e0d6d5884afcdc5a05b23077acfc9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/499081
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@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>
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>
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>
We previously just showed "<unnamed extension>" for extensions without names, but in some files I noticed we have a lot of these, and the outline/symbols list looks awful (just "<unnamed extension>" repeated many times).
This changes it to instead show "extension on FooClass" instead (if there is a valid type name). I added a new field to the protocol to support this because the LSP classes convert from those classes (something we've discussed changing, but might be easier later).
Screenshots of before/after are in https://github.com/Dart-Code/Dart-Code/issues/5818
Fixes https://github.com/Dart-Code/Dart-Code/issues/5818
Change-Id: I3885a722443291bfa2419514841469c862b74450
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/464560
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
No more flag, always parse into the new AST, always visit new AST nodes,
always return them as child entities, parent-child structure reflects
the new AST.
So, use `namePart` and `body` where possible. Deprecate previous
properties.
This is still de jure a breaking change, because `parent` of deprecated
properties changes. De facto this required very few changes in google3.
Once this CL lands, I will publish `analyzer 10.0.0`, migrate everything
to new properties, delete deprecated properties, and publish `analyzer
11.0.0`.
Maybe deprecate `NamedCompilationUnitMember.name` and migrate to
subclass specific `name` or `namePart` properties before publishing
`analyzer 10.0.0`. This part is not breaking per se.
* Deprecations in `ClassDeclaration`:
* Properties `leftBracket`, `members`, `rightBracket` are deprecated, use `body` instead.
* Properties `name`, `typeParameters` are deprecated, use `namePart` instead.
* Deprecations in `EnumDeclaration`:
* Properties `leftBracket`, `constants`, `members`, `rightBracket` are deprecated, use `body` instead.
* Properties `name`, `typeParameters` are deprecated, use `namePart` instead.
* Deprecations in `ExtensionDeclaration`:
* Properties `leftBracket`, `members`, `rightBracket` are deprecated, use `body` instead.
* Deprecations in `ExtensionTypeDeclaration`:
* Properties `leftBracket`, `constants`, `members`, `rightBracket` are deprecated, use `body` instead.
* Properties `constKeyword`, `name`, `representation`, `typeParameters` are deprecated,
use `primaryConstructor` instead.
* **Breaking Change:** While the deprecated members mentioned above still exist in the AST,
their parent nodes have changed. This means that code relying on specific parent-child
relationships for these nodes might break.
Bug: https://github.com/dart-lang/sdk/issues/61701
Change-Id: Ic48104da8b029c9b454bbd2336574b7823025565
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/461841
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Changes the analyzer and related packages so that when they refer to
diagnostic constants, they do so via the import prefix `diag`, which
refers to the appropriate `diagnostic.dart` file containing the top
level diagnostic constant declarations, rather than the static
declarations inside `DiagnosticCode`-derived classes (which will soon
be removed).
This CL was created by the following steps:
- Run the script
`pkg/analyzer_utilities/tool/messages/switch_to_toplevel_diagnostics.dart`.
- Execute `dart fix --apply --code=unused_import,unnecessary_import`
on the following directories (this removes imports that are no
longer necessary due to the change):
- `pkg/analysis_server`
- `pkg/analyzer`
- `pkg/linter`
- `pkg/analysis_server_plugin`
- `pkg/analyzer_plugin`
- `pkg/analyzer_testing`
- `pkg/front_end`
- `pkg/analyzer_cli`
- Execute `dart format` on the following files and directories:
- `pkg/analysis_server`
- `pkg/analyzer`
- `pkg/linter`
- `pkg/analysis_server_plugin`
- `pkg/analyzer_plugin`
- `pkg/analyzer_testing`
- `pkg/front_end/test/scanner_test.dart`
(Note that `pkg/front_end` and `pkg/analyzer_cli` are not
re-formatted as whole directories because they contain `.dart` files
that are test cases rather than source code, and reformatting those
files might change test expectations.)
- Manually add `diag` to
pkg/front_end/test/spell_checking_list_tests.txt.
- Manually fix the ignore comment in
`pkg/analyzer_testing/lib/src/analysis_rule/pub_package_resolution.dart`. (The
script `switch_to_toplevel_diagnostics.dart` automatically adds it
after `import 'package:analyzer/src/diagnostic/diagnostic.dart' as
diag;`, but then executing `dart format` bumps the ignore comment to
the following line, where it has no effect.)
Change-Id: I6a6a69643022aab2b5a6224fb4124eead243260d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/461521
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Renames `pkg/analyzer/lib/src/diagnostic/diagnostic.dart` to
`pkg/analyzer/lib/src/diagnostic/diagnostic_message.dart`. The new
name aligns better with the library's purpose (which is solely to
export the class `DiagnosticMessageImpl` from
`package:_fe_analyzer_shared`).
This frees up the filename
`pkg/analyzer/lib/src/diagnostic/diagnostic.dart` to be used as the
repository for all generated analyzer messages.
Change-Id: I6a6a6964be0904a383334974f1e64a03c0df551b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/458381
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
One can see that we have bare HTML in these signature-in-comments,
like:
"contextMessages": optional List<DiagnosticMessage>
These are flagged by the unintended_html_in_doc_comment lint rule.
This CL solves this by indenting these signatures 4 spaces, making
them Markdown indented code blocks. Alternatively we could use
backticks. Backticks would make the comments taller; indenting makes
them wider. I would prioritize whichever style is less intrusive when
reading them in plain text, which I think would be to use
indentation.
Change-Id: I019d9073e994a505325194ceeac3c6e0635d947e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/453642
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
This renames the old screen, "Legacy plugins" and adds a new screen,
"Plugins". On the new plugins screen, we ask the plugins isolate(s) for
their plugins details, and print the following, for eadh plugin:
* the plugin's name
* the names of the registered lint rules
* the names of the registered warning rules
* the IDs and "messages" of the registered assists
* the IDs and "messages" and associated diagnostic codes of the
registered quick fixes
More to come in follow ups:
* The resolved versions of plugin packages (coming from package_config.json)
Change-Id: Ic3dc4c5bffa64fd4da4097c042a847cc064e41ce
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/447763
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This change adds a new parameter `typeParametersInScope` to `DartEditBuilder.writeType`, and related methods to deprecate the previous `methodBeingCopied` parameter, which limited our ability to pass in some type parameters that are in scope.
Also fixes a TODO about testing if the `Record` feature is enabled or not.
And as a bonus, we now always write down type parameters by looking for the closest public type or falling back to `Object?` or `dynamic`.
Bug: https://github.com/dart-lang/sdk/issues/61186
Change-Id: I7a7b1c62adb81aecfdf61ebbaa0d95f1d33bced8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/442282
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Auto-Submit: Felipe Morschel <git@fmorschel.dev>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
This change was generated by the following process:
- The script `pkg/analyzer/tool/messages/rename_error_constants.dart`
was run. This generated the vast majority of the diffs.
- Then all modified files were reformatted using
`tools/sdk/dart-sdk/bin/dart/format`.
- Finally, the script `pkg/analyzer/tool/messages/generate.dart` was
run, to rebuild generated code.
Change-Id: I6a6a69644ed8740ad6269d98cb169076151824ed
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/444921
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Because ChangeBuilder can be used to modify multiple files, the EOL should come from an individual files edit builder and not from the overall ChangeBuilder.
This change renames `eol` on ChangeBuilder to `defaultEol` (since it's still useful to supply a custom default, for example when moving a class from an existing file to a new file, we want to default to the same EOL as the source file), and adds an EOL to file edit builders which is computed from the file content (and falls back to the default from ChangeBuilder if there are none).
My intention here is to not introduce any breaking changes (yet) so the ChangeBuilder constructor interface still has the "eol" named parameter (marked as deprecated) as well as the new `defaultEol` parameter.
I added a new `StringExtension` for `endOfLine` to both analyzer_plugin and analysis_server_plugin as we need this in both places (but I expect one of those projects will ultimately be dropped). This slightly differs from `CorrectionUtils.endOfLine` because it can return `null` which is a signal to fall back to the ChangeBuilder default instead of forcing its own default. (CorrectionUtils.endOfLine now uses that extension, although because of the null/default, it's likely that some - if not all - uses of this should migrate to the new extension and fall back to a default from a ChangeBuilder).
Change-Id: Ie2e6eaba78c96a1cbd79eba881e12bbeef724aa8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/443122
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
This change mainly has side effects for code completion, making sure we're suggesting the right members. When the user writes something like `E e = .^` where `^` is the cursor, they're most likely intending to write a dot shorthand.
So this parser recovery change ensures that we recover as a dot shorthand node and not as a prefixed identifier (missing it's target) in the analyzer. We don't need special casing in the code completion pass to handle dot shorthands in the prefixed identifier visitor now.
The CFE should have no notable changes, but I added a few tests since it uncovered some crashing behavior. The duplicate errors have always been the case even prior to this change.
Bug: https://github.com/dart-lang/sdk/issues/59836
Change-Id: I6c4a9f2c8cc376e4dedd715af76967da471aa681
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/439140
Commit-Queue: Kallen Tu <kallentu@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Varad Raj Agrawal