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>
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>
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>
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>
Changes the logic for deciding whether to output details about a top
level element. Previously, details would be output if the library
containing the element's declaration was in `lib` but not
`lib/src`. This led to a bug: if a top level element was declared in
`lib/src` but exported by an `export` directive in `lib`, no details
would be output, and the API summary would just show `(non-public)`
after the exported name.
This bug was mostly benign because we were working around it with an
analyzer-specific hack: when analyzing the `analyzer` package, top
level elements with an annotation of type `AnalyzerPublicApi` would
have their details output regardless of where they were declared. But
it wasn't completely benign: the tool was failing to output details of
`DartDocumentLinkVisitor` and `DocumentLink` (from
`package:analyzer_plugin`), as well as `PackageBuilder` (from
`package:analyzer_testing`).
The new logic is: details are output if the element appears in the
export namespace of any library in `lib` but not `lib/src`. I've
re-run the API summary tool so the `api.txt` files in
`package:analyzer_plugin` and `package:analyzer_testing` now include
the details they were missing.
The analyzer-specific hack is left in place, though, because there are
some analyzer classes that aren't exported, but still considered part
of the analyzer public API. In a follow-up CL, I will make the API
summary tool extensible so that this analyzer-specific logic can be
injected by the analyzer when generating its `api.txt` file, and it
won't pollute the incipient `api_summary` tool.
Change-Id: I6a6a69641d656caa4f8e6361557c13fa7485e422
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/482440
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Adds the modifiers `abstract`, `base`, `final`, and `interface` to the
API summary output.
This information is an important part of the public API of a package,
because it determines whether a client can:
- Construct an instance of the class,
- Extend the class, or
- Implement the class.
Change-Id: I6a6a6964ba07db1714bc2fcb549cc15230e87058
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/482362
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Fixes two minor bugs with the sorting of members in the API summary
tool:
- The technique for placing getters next to their corresponding
setters was to sort them lexicographically based on
`Element.apiName`, which in the case of setters appends `=`. This
mostly worked, but due to the fact that `=` is between `9` and `A`
in ASCII, it was wrong in a few corner cases. For example, it would
sort `x`, `x=`, `x1`, and `x1=` in the order `x`, `x1`, `x1=`,
`x=`. Fixing this didn't affect any `api.txt` files in practice.
- The technique for sorting constructors also used `Element.apiName`,
which in the case of an unnamed constructor is `new`. This meant
that if a class had both named and unnamed constructors, the unnamed
constructor would not always be sorted before the other
constructors.
The fix for both bugs is to sort by `Element.name` (which does not add
`=` for setters and is the empty string for unnamed constructors), and
then to break ties by explicitly checking whether the element is a
setter.
Change-Id: I6a6a69648fb5915266a9111c5d884531bba4405d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/482361
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@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>
Konstantin Shcheglov