This paves the way for a follow-up CL that will standardize all
diagnostic names to `lower_snake_case` conventions.
For now, the case differences between the entries in
`error_fix_status.yaml` and the actual diagnostic code names are
accounted for by adding some calls to `.toLowerCase()` to
`verify_error_fix_status.dart`.
Change-Id: I6a6a6964b0eacf50b11f302ab511fba149b1ac07
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/465981
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Fixes https://github.com/dart-lang/sdk/issues/61684
This caching is based largely on the `--depfile` feature offered by
`dart compile`, which is based on a Ninja depfile concept
(https://ninja-build.org/manual.html#_depfile), which spits out a file
(`depfile.txt` here) which lists all of the input files which were
required to build an AOT snapshot.
The process is essentially:
1. If an AOT snapshot is found, maybe use it as a cached snapshot!
a. If the `pubspec.yaml` modification timestamp is newer, re-compile!
b. If the `.dart_tool/package_config.json` modification timestamp is
newer, re-compile!
c. If the `bin/plugin.dart` modification timestamp is newer,
re-compile!
d. If the `bin/depfile.txt` file is missing or malformed, re-compile!
e. If any files mentioned in `bin/depfile.txt` have a newer
modification timestamp, or don't exist, or are an otherwise bad
path, re-compile!
f. Otherwise, save a dozen seconds and use the cached snapshot.
Change-Id: Icc747198f8af76d256ac915685473d6f529a3cef
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/464602
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Work towards https://github.com/dart-lang/sdk/issues/61684
PluginManager needs to be more testable before implementing the caching feature. This CL lays the groundwork.
We add ProcessManager.runSync, and a handler for that in MockProcessHandler. Then we can add tests which call `PluginManager.filesFor` with `isLegacy: false`, and `dart pub upgrade` will not be run on the real filesystem.
Change-Id: I7b8877d985296741e51543c10a7cb87c8a43c116
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/465662
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@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>
Modifies the code generation logic that populates the
`DiagnosticCode.uniqueName` field so that it doesn't include the
diagnostic's class name.
This paves the way for removing the last remenants of the diagnostic
classes from the analyzer.
Change-Id: I6a6a696453fe1f2bd8bd3cea00a9a496392fbf98
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/464240
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Sam noted that AOT snapshots might return `dartaotruntime` for `Platform.resolvedExecutable`. It doesn't seem to happen if you invoke server with `dart language_server` because `dart` is still the executable, but if you invoked the snapshot directly with `dartaotruntime` then this would fail.
To avoid any possibly issues, this changes it to use the same `sdk.dart` getter that some other code uses that handles this difference by constructed the path to the `dart` executable.
Change-Id: I099335a255a792b6754d8d2a1f0bde491c09699e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/464681
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This adds error recovery for explicitly naming a constructor 'new' with the new constructor syntax. This is not allowed so an error is explicitly emitted while handling this.
Change-Id: Iac3045f04c9c75779ffb2d9e866817ac43ab5d26
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/463281
Reviewed-by: Jens Johansen <jensj@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@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>
This `socketError` callback doesn't record exceptions to the instrumentation service because they were expected to be things like the socket closing. However it was also used for unhandled errors in the zone used for handling errors, which meant they also were not logged. This meant the user would see the error text, but the stack trace would never be logged anyway.
With this change, unhandled exceptions from the zone will be logged through the instrumentation service too.
Fixes https://github.com/dart-lang/sdk/issues/62082
Change-Id: I71d56a8b3c9241744eb614d74de46c190d61f2e3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/464381
Commit-Queue: Keerti Parthasarathy <keertip@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
Changes the null check in `if (stackTrace != null && exception is!
CaughtException)` from `!=` to `==`. The test was clearly intended to
supply a stack trace if (a) there isn't one already, and (b) one can't
be obtained from `CaughtException`. But with the accidental use of
`!=`, what it was actually doing was destroying the stack trace
supplied by the caller in the circumstance where `exception` was not a
`CaughtException`.
This should make it easier to debug some trybot failures that are
occurring in https://dart-review.googlesource.com/c/sdk/+/464245.
Change-Id: I6a6a6964072bf58db0bcddb22492b0a70203d43a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/464460
Auto-Submit: Paul Berry <paulberry@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Previously, the process for removing a lint from `pkg/linter` was the
following:
- Remove the lint class's override of
`AbstractAnalysisRule.registerNodeProcessors` (effectively changing
the rule into a no-op).
- Change its override of `AnalysisRule.diagnosticCode` to return the
pseudo-diagnostic code `removedLint`.
- Modify its constructor to use `RuleState.removed`, so that the lint
would be marked as being in the "removed" state.
This change introduces a new class, `RemovedAnalysisRule`, as the
standard way to represent an analysis rule that has been removed. So
the new process for removing a lint from `pkg/linter` will be to
remove its class entirely and instead register an instance of
`RemovedAnalysisRule`.
This avoids the need for the pseudo-diagnostic code `removedLint` to
exist at all, and also makes the representation of a removed lint much
more compact.
To help encourage clients to use the new `RemovedAnalysisRule` class,
the `RuleState.removed` constructor has been deprecated. It will be
removed in a future version of the analyzer.
Change-Id: I6a6a6964726595b7bb32664846cf4e4722bbb4f1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/463463
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This reverts commit 19b345cadc.
Reason for revert: Breaks analysis server / VSCode integration.
Original change's description:
> Do not rebuild contexts on Linux if there is a error indicating the watcher limit has been reached. This prevents the hang for the cli.
>
> In the IDE, tested on both VS Code and IntelliJ, a message is shown when there are no watchers.
>
> For the cli, there is no message shown now. To do so we would need to plumb through the messaging, as this exception happens when we set roots, and there is no exception handling there.
>
> Like to land this before looking into that.
>
> https://github.com/dart-lang/sdk/issues/61931.
>
> Change-Id: Iaae9a85e646dfed4015e130076265be39b932f1c
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/463062
> Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
> Commit-Queue: Keerti Parthasarathy <keertip@google.com>
Change-Id: Ief7cab1974535c526030803ab7624f6a9fc06844
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/463700
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Removes all the generated classes derived from `DiagnosticCode` that
are specific to a type of diagnostic, except for those associated with
lints (`LinterLintCode`, `LinterLintWithoutArguments`, and
`LinterLintTemplate`). These exceptions are needed because the base
class for lint codes, `LintCode`, is part of the anlyzer public API,
and so it's necessary for lint codes to all implement it.
The generated static constants in these classes are removed too
(including the ones in `LinterLintCode`), since they are no longer
used; the analyzer and related packages have all been transitioned
over to refer to top level diagnostic constants instead.
Note that the class `ParserErrorCode` could not be completely removed,
because it is dependend upon by `package:dart_style`. So a stub
version of it is added to
`package:analyzer/src/dart/scanner/scanner.dart` (the file that
`package:dart_style` imports it from) as a temporary workaround.
Change-Id: I6a6a69648acac350e4e2249efe50ae9c652772b2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/461880
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
In the IDE, tested on both VS Code and IntelliJ, a message is shown when there are no watchers.
For the cli, there is no message shown now. To do so we would need to plumb through the messaging, as this exception happens when we set roots, and there is no exception handling there.
Like to land this before looking into that.
https://github.com/dart-lang/sdk/issues/61931.
Change-Id: Iaae9a85e646dfed4015e130076265be39b932f1c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/463062
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Keerti Parthasarathy <keertip@google.com>
This improves the error recovery for syntax like `new C.named();`. Previously, the parser would derail with messages like "A method declaration needs an explicit list of parameters" and a cascade of other errors.
With this change the qualified name is recognized as an attemp to write the name of the constructor, reporting that qualified names are not allowed in this case.
Part of https://github.com/dart-lang/sdk/issues/61699
Change-Id: Id1062aac3b90db8d2346013cf8a0bd9a541b9a3c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/463020
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Adds missing `status` entries to the analysis server's
`error_fix_status.yaml` file.
The reason these were missing was because currently, the only
validation logic that checks that `status` entries are present is in
`pkg/linter/tool/machine.dart` (the `readFixStatusMap` function), and
it ignores entries that don't start with the class name prefix
`LintCode.`.
This paves the way for a follow-up CL that will remove the class name
prefixes from `error_fix_status.yaml` entirely (as part of a larger
effort to remove those classes from the codebase).
Note that the validation logic in `readFixStatusMap` is not really
very robust; it only checks that the `status` entries are strings. In
a follow-up CL I will add a more thorough check.
Change-Id: I6a6a69644f7cc07162f5614c87149d6e72b99d23
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/462700
Commit-Queue: Paul Berry <paulberry@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>
This adds a page on which users can start and stop the collection of
log entries and then copy and paste those entries either to send to us
or to write a scenario.
I changed my mind about the interaction style I wanted on this new page,
so I had to modify the in-memory session log sink slightly.
I also changed one of the labels to reflect the rename to the insights
pages.
Change-Id: I460668047d777f2ee98764ecff7845ea2d2fda99
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/462244
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Adds a new logging sink that supports an in-memory storage of events for
a subset of the whole server session. This is support for being able to
add 'start' and 'stop' buttons to the insight pages, which will allow
us and users to capture a smaller number of log entries.
Change-Id: Ia562e4da7b09c11ad9191c24cb85102970e1b116
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/461901
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Jake Macdonald <jakemac@google.com>
Paul Berry