Work towards https://github.com/dart-lang/sdk/issues/60635
* `AnalysisError._contextMessages` unnecessarily backed the public
`contextMessages` getter; the field is final so it can be public
itself.
* `AnalysisError._correctionMessage` unnecessarily backed the public
`correctionMessage` getter; the field is final so it can be public
itself.
Change-Id: If269d4ed590ef7df81d9b9e3be03766601526d7f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/425620
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Sometimes - on responding to `edit.getFixes` requests, the method
`getTopLevelDeclarations` is called several times with the same
parameter and caching has then sometimes sped things up.
I then also noticed that it caused `reportAnalysisAnalytics` to be
called many times (e.g. 73 times for one `edit.getFixes` request)
each time spending time collecting data which - on passing to
`analyticsManager.analysisComplete` - was just thrown away because it
only saves the first one.
Combined these changes have been observed to reduce the response time
on `edit.getFixes` by up (down?) to ~20% (e.g. from 5 seconds
to 1 second).
In response to http://b/407797012 where more data is also available.
Unfortunately I haven't been able to reproduce this is a benchmark
(yet anyway). I don't know if it needs slower slower reads, an extreme
amount of files, several contexts or something else entirely.
Change-Id: Id214b0e1b7d8bbef7f6d956408f17fab45618b78
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/420323
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
A few statements around the package read:
> Producers used in bulk fixes must not modify the FixKind during
> computation.
In fact, this `add_null_check` correction producer seems to be the
_only_ remaining producer that violates this statement. In order to
fix it, such that `fixKind` is set during constructor initialization,
we must do some poking around the AST.
So we convert `_computeTarget` to be static (and change it to also
compute and return any possible null-aware token, renaming it to
`_computeTargetAndNullAwareToken`). We also convert `_isNullAware` to
be static. Then the two public constructors are converted into
factory constructors that determine the fix kind, and store the
`_target` and `_nullAwareToken` in fields, so as to avoid re-computing
them during `compute()`.
Change-Id: Ic66319ef764dd9bd69f0e1059347acf174debb25
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/419420
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
The `DartFixContext.librariesWithExtensions` utility function accepts
a `memberName` parameter but never did anything with it. This change
adds filtering in that function based on the member name.
This code depends on the set of exported extensions, which is provided
in an extension (`LibraryElementExtensions.exportedExtensions`) in the
analysis_server package, which must be moved to the analyzer package.
Change-Id: I06c8a9a0e11ceb70e75517b30c0b048321d6b024
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/418641
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
To support this feature:
* Remove `DartAssistContextImpl` as it has no differences from
`DartAssistContext`. Thus the getters `DartAssistContext` are made
into fields, and all callers now call `DartAssistContext()`.
* Add a top level `computeAssists` function, similar to the top-level
`computeFixes` function.
Change-Id: I3ef5fd9ee9430150004b29c11ab972939b85b214
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/417360
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
This is a reland of commit b9b77058a9
Original change's description:
> Migrate to use pub workspace
>
> Use `pub get` to generate `.dart_tool/package_config.json` on gclient sync.
>
> All pkg/ (and a few third_party) packages that are developed inside the sdk repo are included in the workspace from the root `pubspec.yaml`.
>
> All dependencies that are pulled in via DEPS are added as path dependencies via `dependency_overrides` in the root `pubspec.yaml`.
>
> Bug: https://github.com/dart-lang/sdk/issues/56220
> Change-Id: I38c12b608c68da54c57821116cf9aa6696936746
> Tested: relies on CQ of existing tests. Should have no effect on functionality
> CoreLibraryReviewExempt: only core library change is adding a `// ignore:` comment. Should have no influence on functionality
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/397164
> Commit-Queue: Sigurd Meldgaard <sigurdm@google.com>
> Reviewed-by: Alexander Thomas <athom@google.com>
Bug: https://github.com/dart-lang/sdk/issues/56220
Change-Id: I29afabade2d2447dea05121cb87ff50bb21a4b76
Cq-Include-Trybots: luci.dart.try:flutter-linux-try,flutter-web-try
Tested: relies on CQ of existing tests. Should have no effect on functionality
CoreLibraryReviewExempt: only core library change is adding a `//
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/415561
Commit-Queue: Sigurd Meldgaard <sigurdm@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
The PluginServer class needs access to AssistProcessor in order to
compute assists. That class needs access to a few other classes, which
then must also be moved:
* assist_core.dart - the Assist class
* assist_dart.dart - the DartAssistContext class
* assist_generators.dart - the registeredAssistGenerators variable
* assist_performance.dart - the AssistPerformance and
GetAssistsPerformance classes
* assist_processor.dart - the AssistProcessor class with it's
singular API, `compute()`
* performance.dart - the ProducerRequestPerformance class
* the `addCaretAtOffset` helper function, refactored into a
`withCaretAt` extension method
This change is functionally a no-op.
Change-Id: Ic883d21e9cc8c3db1f6093f830f01ec6eb9a0976
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/416680
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
This reverts commit b9b77058a9.
Revert "Add missing sample pubspec to workspace"
This reverts commit 892ea15ac7.
These seem to break the engine.
Change-Id: Ieee26deb7928c3869a1b6265326c3ce568ffe731
Tested: this is a revert.
CoreLibraryReviewExempt: this is a revert
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/415582
Commit-Queue: Sigurd Meldgaard <sigurdm@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Use `pub get` to generate `.dart_tool/package_config.json` on gclient sync.
All pkg/ (and a few third_party) packages that are developed inside the sdk repo are included in the workspace from the root `pubspec.yaml`.
All dependencies that are pulled in via DEPS are added as path dependencies via `dependency_overrides` in the root `pubspec.yaml`.
Bug: https://github.com/dart-lang/sdk/issues/56220
Change-Id: I38c12b608c68da54c57821116cf9aa6696936746
Tested: relies on CQ of existing tests. Should have no effect on functionality
CoreLibraryReviewExempt: only core library change is adding a `// ignore:` comment. Should have no influence on functionality
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/397164
Commit-Queue: Sigurd Meldgaard <sigurdm@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
This updates `analyzer_use_new_elements` lint to stop reporting inside
deprecated declarations. So, we can deprecated and prepare for removal.
Apply deprecation dart/analysis/results.dart
Deprecate `ElementDeclarationResult`, add `FragmentDeclarationResult` instead.
Change `getFragmentDeclaration` (not yet published) return type to `FragmentDeclarationResult` to better correspond to the method name.
Rename `getElementDeclaration` from `AnalysisSessionHelper` to
`getFragmentDeclaration`, to better reflect on what it operates.
Change-Id: I2839c9a7e21ed2e5b34035fc8c3ec88fd23df1b5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/412840
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
The code that was previously owned by the analyzer team
(OWNERS_ANALYZER) is now owned by either the Dart Model team
(OWNERS_MODEL) or the developer experience team
(OWNERS_DEVELOPER_EXPERIENCE). Accordingly, we don't need
OWNERS_ANALYZER anymore.
Change-Id: I9a4d2e2462a15ba9ec8f3046cdca77ba9d3af13c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/410564
Reviewed-by: Kevin Moore <kevmoo@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Moving forward, the Developer Experience team will own the following
packages:
- analysis_server
- analysis_server_client
- analysis_server_plugin
- analyzer_plugin
- language_server_protocol
- linter
- meta
- server_plugin
- telemetry
In follow-up CLs I will create an OWNERS file for the Dart Model team,
and then remove the OWNERS files for the old analyzer and CFE teams.
Change-Id: Icc52ca75e92baf9d05de211e9e3f6c36fb19b71e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/409860
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Reviewed-by: Kevin Moore <kevmoo@google.com>
Some time ago, the analyzer team decided to adopt the convention of
using `TODO` comments to document long term issues that should persist
in the codebase, and `FIXME` comments to document short term issues
that need immediate attention.
Accordingly, it makes sense to suppress `TODO` comments from being
surfaced to the IDE "problems" view (since there can be a lot of them,
and they're not immediately actionable). This makes VSCode's
"problems" view much more usable in "tree" mode.
(See also https://dart-review.googlesource.com/c/sdk/+/295662, which
made the corresponding change to the `analysis_server` and `analyzer`
packages, https://dart-review.googlesource.com/c/sdk/+/325121, which
made the corresponding change to the `linter` package, and
https://dart-review.googlesource.com/c/sdk/+/358980, which made the
corresponding change to the `analyzer_plugin` package).
Change-Id: I916c8c7f435d06c1b0bd871ef3829d58c9242218
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/410060
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Auto-Submit: Paul Berry <paulberry@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This change allows the LegacyAnalysisServer to understand when the
plugin isolate (if there is one) is analyzing or not. There are a few
primary concepts:
* The plugin isolate (PluginServer) notifies the analysis server, when
analyzing all files in a context collection, and analyzing changed
files, that it is analyzing, and later that it isn't.
* The NotificationManager tracks whether the plugin isolate is analyzing
or not, based on the last status.
* The PluginManager tracks whether new plugins are initialized or not.
This is determined by the work done by the PluginWatcher. If no
plugins are configured, then plugins are declared to be "initialized".
Otherwise, the AnalysisServer sets their status to be "initialized"
after receiving the first status notification from the plugin isolate.
* The LegacyAnalysisServer now uses the additional "are plugins
analyzing" signal, held in NotificationManager, and the "are plugins
initializing" signal, held in PluginManager, to determine whether to
notify the client that analysis is complete.
Change-Id: Ie2b6a6048f074d7a26d7d5d07622a17c30fcab96
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/405444
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Sam Rawlins