Move another batch of analyzer tests away from offset-based
assertErrorsInCode() expectations. Put expected diagnostics and context
messages directly in the source snippets instead, including multi-file
cases that need context markers in supporting files.
This keeps each diagnostic expectation next to the code that produces
it, making the tests easier to read and less fragile when surrounding
code changes. It also removes now-unused diagnostic imports and helper
parameters that were only needed for explicit ExpectedDiagnostic lists.
Update the diagnostic expectation utilities so stripping generated
marker lines preserves the retained source lines correctly.
Change-Id: Ibe3890b9ff5e2b2e102e13e5ecc243bdf80c5f4b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/509682
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Add helpers that resolve non-test files using the same inline diagnostic
expectation format as resolveTestCodeWithDiagnostics.
resolveFileWithDiagnostics handles a single file, while
resolveFilesWithDiagnostics writes all related files before resolving
any of them.
Add multi-file diagnostic expectation generation so context messages in
one file can be referenced from diagnostics reported in another. Teach
expectation updating how to target values in a files-to-code map using
per-entry intra-invocation ids.
Remove assertErrorsInFile2 and migrate diagnostics tests from
hand-written ExpectedError offsets to inline markers. This keeps the
diagnostic range, code, message, and cross-file context next to the code
under test, and makes expectation updates reusable for library and part
tests.
Initialize strong-mode type assertions from resolveFile so callers that
resolve files other than testFile get the same setup.
Change-Id: Ie492155b046c28a535faf21fa9a2e47797caffb0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/506180
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Add support for keeping parser diagnostic expectations in the source
snippets they describe. Expectations are written as caret markers and
diagnostic comments, and regenerated from the parser's actual
diagnostics before comparison.
This keeps parser recovery expectations close to the code under test and
removes the need to maintain offset-based `assertErrors` lists by hand.
The updater also removes existing expectation markers before writing the
canonical form, so marked snippets can be refreshed in place.
Migrate recovery parser and class parser tests to the new
`assertExpectedDiagnostics` helper, including no-error cases where an
unmarked snippet is the expected canonical form.
Update `test_runner` to exclude `/pkg/analyzer/` from searching static
error expectations.
Bug: https://github.com/dart-lang/sdk/issues/63335
Change-Id: Ic9866da8cc601c6b360552ba576e8aa1646f89a5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/501340
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Bob Nystrom <rnystrom@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>
This CL enables the primary constructors feature by default in Dart 3.13.
The primary constructors feature is a brevity feature. There are no new semantics, but it allows us to express declarations in a less verbose way.
This feature allows one constructor and a set of instance variables to be specified in the header of a declaration.
Currently a declaration with a constructor and some fields is written as:
```dart
// Current syntax.
class Point {
int x;
int y;
Point(this.x, this.y);
}
```
With a primary constructor, we would write the above as:
```
class Point(var int x, var int y);
```
If a primary constructor needs an initializer list or a body, they can be
specified inside the class using the `this` body syntax:
```dart
class Point(var int x, var int y) {
this : assert(x >= 0) {
print('Point created at $x, $y');
}
}
```
As part of this feature, you can also use the `new` and `factory` keywords to
declare constructors in the class body without repeating the class name:
```dart
class Point {
int x, y;
// Equivalent to Point(this.x, this.y)
new(this.x, this.y);
// Equivalent to Point.origin()
new origin() : x = 0, y = 0;
// Equivalent to factory Point.clone(Point other)
factory clone(Point other) => Point(other.x, other.y);
}
```
To learn more about the feature, check out the feature specification located here: https://github.com/dart-lang/language/blob/main/accepted/future-releases/primary-constructors/feature-specification.md
Tested: Has existing language, CFE, analyzer, analysis server tests.
Bug: https://github.com/dart-lang/sdk/issues/61524
Change-Id: I296f2fcd918b87bf2a1dd00256340759866c2423
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/489241
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Michael Thomsen <mit@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
Reviewed-by: Ben Konyi <bkonyi@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>
The Flutter Widget Preview feature is currently implemented within
Flutter Tools, which is responsible for detecting widget preview
annotations in the user's project. When previews are detected, the
Flutter Tool injects code generated based on the detected previews into an artificial widget_preview_scaffold project and performs a hot reload to render updates to the preview set in the scaffold application.
`package:analyzer` is currently being used to detect previews, but this comes with a significant amount of memory overhead. Since widget
previews are mostly being used from within IDEs which already have an
active analysis server, moving widget preview detection into the DAS
will remove the need for creating an additional analysis context in the Flutter Tool itself.
This change includes the initial work to move widget preview detection
into the DAS. It utilizes a pull-based mechanism, where the Flutter Tool listens for file system events and then queries the DAS using the `dart/textDocument/getFlutterWidgetPreviews` and `dart/workspace/getFlutterWidgetPreviews` LSP methods.
Each reported preview contains some generated code based on the annotation used to define the preview. This code has all constants from the original annotation evaluated to either primitive values or constant expressions with namespaces applied to each symbol, allowing for the Flutter Tool to inject this code directly when updating the generated code in the scaffold project.
Towards https://github.com/flutter/flutter/issues/179584
Change-Id: I043cb3235a66b25dda3f852ca7f147bff0e1e537
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/478100
Auto-Submit: Ben Konyi <bkonyi@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@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>
These tests cover all the functionality of the API summary tool.
Note that since the `ApiDescription` constructor requires an
`AnalysisContext`, I added a public `contextCollection` getter to the
`PubPackageResolutionTest` base class.
There are a few loose ends I intend to address in follow-up CLs. They
have been noted in TODO comments:
- Annotate when classes are `abstract`, `final`, or `interface`.
- Move `pub_package_resolution.dart` out of
`package:analyzer_testing/src` (so that when I publish this as a
separate package, that package won't be dependent on private
implementation details of `package:analyzer_testing`).
Change-Id: I6a6a69643064115997f6586ff5161ddf4c9f96ff
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/482360
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Moves the following classes from
`package:analyzer/analysis_rule/analysis_rule.dart` into
`package:analyzer/src/analysis_rule/analysis_rule.dart`:
- `AbstractAnalysisRule`
- `AnalysisRule`
- `MultiAnalysisRule`
- `RemovedAnalysisRule`
These classes are part of the analyzer public API, so the file
`package:analyzer/analysis_rule/analysis_rule.dart` remains, exporting
the declarations so that they can still be used by clients.
This paves the way for a follow-up CL that will use extensions to add
functionality that we *don't* want to include in the analyzer public
API yet.
Change-Id: I6a6a696431f00f69b4b80e0d98b1b8fbb33f020f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/481164
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Changes the test logic in `analysis_server` and `analyzer_testing` so
that after printing `To accept the current state, expect:`, it prints
diagnostic codes in their proper camelCase format.
Also removes some bogus code from
`pkg/analyzer_testing/lib/analysis_rule/analysis_rule.dart` that
erroneously suggested passing a `name:` parameter to the top level
`error` function. This function does not accept any parameter called
`name`.
Previously, only tests in `pkg/analyzer/test` printed the diagnostic
codes correctly.
Fixes https://github.com/dart-lang/sdk/issues/62651.
Change-Id: I6a6a6964b17cf798c1355e09f9a4633e1fbe388c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/480041
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
These extensions were previously in `pkg/analyzer_utilities`, which is
not published on `pub`. That meant they could not be used from within
the `lib` directory of any package that *is* published on
`pub`. Specifically, they could not be used from within
`pkg/analyzer_testing/lib`.
In a follow-up CL, I will modify the testing logic so that after
printing `To accept the current state, expect:`, it prints diagnostic
codes in their proper camelCase format.
Change-Id: I6a6a696432d7162906b2c235ea88310dc0aa1fa9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/480040
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Konstantin Shcheglov