Work towards https://github.com/dart-lang/sdk/issues/60635
I tried to keep this minimal but still sensible:
* Rename AnalysisErrorListener and all subtypes to use 'Diagnostic'.
* Rename all instantiations of such classes if they previously
contained the word 'error'.
* Rename `RecordingDiagnosticListener.errors` to `.diagnostics`.
* Rename some _testing_ instance members that had the word 'error'
to instead use 'diagnostic'.
Change-Id: I3948e27ba28ac2494092e04f4e1d201a20cc1135
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/433004
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This allows us to traverse the children without needing to create lists.
It also allows us to iterate over lists of nodes more efficiently.
Tested against the script that computes fixes for 10,000 diagnostics,
I'm seeing the following result.
Before this CL the average time was 10692.4 ms.
After this CL the average time was 1900.0 ms.
That's just over an 82% improvement.
Change-Id: Ideff745288c8990e9948b22c5204d176af3cac6e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/426904
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@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>
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>
In many cases, AnalysisOptions is sufficient.
* ResolvedCorrectionProducer will be public API for someone writing an
analyzer plugin; it should not expose an AnalysisOptionsImpl. Luckily
the only need for the Impl, today, is in the "ignore diagnostic" fixes
so we can cast in there. (We could also expose the `file` and the
`unignorableNames` fields.)
* Some other spots only cast in order to access one of the 'strict'
fields, but all of those have been made public.
* AnalysisOptionsImpl.enabledLegacyPluginNames can be made final.
* Many other users don't need AnalysisOptionsImpl, or only need it to
pass it to other code that _does_ need it. In many of those cases it
makes sense to look at an object as an AnalysisOptions, and let the
code that needs a field from Impl to do a cast.
Change-Id: I3640934fb9d93c9b95f15a22457af604e420c7a9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/392240
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
FixProcessor has to be part of the analysis_server_plugin package, so
it cannot have any dependencies on the analysis_server package. This moves one.
The word 'default' is reserved, so I changed to 'standard'.
Cq-Include-Trybots: luci.dart.try:flutter-analyze-try,analyzer-win-release-try,pkg-win-release-try
Change-Id: I1ee21c800203fac758f10a6fde0ea7d07eee5e7f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/374742
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
This brings the soft static enforcement that we had before: a producer
that extends ParsedCorrectionProducer cannot access the
ResolvedUnitResult of a ParsedUnitResult.
Also we add some runtime enforcement that the producers used for parse-
only lint rules are ParsedCorrectionProducer.
Cq-Include-Trybots: luci.dart.try:flutter-analyze-try,analyzer-win-release-try,pkg-win-release-try
Change-Id: If77fa66ae6fc070de1c7e931eb992a4adc14b68a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/369561
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
We do this by passing a CorrectionProducerContext up each of the
constructors. We can then remove all `configure` methods. This
requires a few changes and allows a few changes:
* Remove ParsedCorrectionProducer. It does not seem to have served a
purpose.
* CorrectionProducerContext no longer needs to be generic.
* Add a public getter for `MultiCorrectionProducer._context`, so that
a multi correction producer can pass along its context to child
correction producers.
* Introduce a `CorrectionProducerContext.instance` dummy variable,
used when we need to check if a correction producer can be applied
in bulk.
* Make `CorrectionProducerContext._node` public, so that it can be
used in factory constructors.
* `BulkFixProcesor.correctionContext()` return type is non-nullable.
* Add a factory constructor for AddMissingParameter, and move the
`configure` logic there.
* Add a factory constructor for ConvertAddAllToSpread, and move the
`configure` logic there. Then make `_isInlineInvocation` and
`_invocation` final.
* Add a factory constructor for ReplaceFinalWithVar, and move the
`configure` logic there. Then make `_removeFinal` and
`_finalKeyword` final.
* Add a factory constructor for ReplaceWithIsEmpty, and move the
`configure` logic there. Then make `fixKind`, `multiFixKind`,
`_binary`, and `_replacement` final.
* Rename `_AddMissingParameter.context` to `_executableParameters`,
and make it final.
Cq-Include-Trybots: luci.dart.try:flutter-analyze-try,analyzer-win-release-try,pkg-win-release-try
Change-Id: If0e9bc1cbf5c8e656938bc6cd4eb32a9d4f06b38
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/368760
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
* Move the only 3 files from server_plugin to analysis_server_plugin.
* Copy some test infra into analysis_server_plugin. This is temporary,
as we need some shared test infra location.
Change-Id: If2b41d436c9d3051e590f60ae2eb7ab31e529321
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/364161
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
We have chosen a new name for this package. So before we write more
code inside, we need to move everything from 'server_plugin' to
'analysis_server_plugin'. There are some steps do doing so, to not
break various infra:
1. Land this change, introducing the new package in the SDK, but no
dependencies on it.
2. Land this change independently in google3 (the package is not
yet "unbundled.")
3. Mark the package as "unbundled" in google3.
4. Move all code from server_plugin to analysis_server_plugin; update
imports; and delete server_plugin.
5. Remove server_plugin as an "unbundled" package; and remove
server_plugin from google3.
Bug: https://github.com/dart-lang/sdk/issues/53402
Change-Id: I70197fdf61dd5862c2220d8ed5dd0880a1593ead
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/363600
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Sam Rawlins