This change adds a `@Deprecated` annotation to each of the analyzer's
generated error code files, with a deprecation message that says the
corresponding non-code-generated file should be imported instead. For
example, `package:analyzer/src/error/codes.g.dart` now has a
deprecation message saying that
`package:analyzer/src/error/codes.dart` should be used instead.
All existing imports of these libraries are switched to the
corresponding non-code-generated file, where possible. (The only
circumstance in which it's not possible is when the corresponding
non-code-generated file imports the code-generated file---e.g., when
`package:analyzer/src/error/codes.dart` imports
`package:analyzer/src/error/codes.g.dart`. In these cases, the
deprecation warning is suppressed with an "ignore" comment.)
This change is part of a long term effort to unify the analyzer and
CFE representations of error messages. It paves the way for a
follow-up CL in which I intend to move some of the generated code from
`package:analyzer` to `package:_fe_analyzer_shared`, to allow it to be
shared with the CFE.
Change-Id: Ie91dc8fc9357defa8974cbe6836d582979d87d81
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/437840
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
So, now VariableElementImpl implements ConstantEvaluationTarget, and VariableElementOrMember no longer implements ConstantEvaluationTarget.
Correspondingly, all constant related logic and methods were removed from subclasses of `VariableFragmentImpl`, and added to `VariableElementImpl`.
This moves us toward the goal of using elements instead of fragments almost everywhere. Fragments should be used in a sense only "locally" as a way to build elements.
Change-Id: I79ae77c4c53174c6860031ffc9b586ca65d83a37
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/437681
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
The two pieces of information we're tracking are
- the number of libraries in each library cycle
- the number of lines of code in each library cycle
The data is reported in terms of percentage.
This doesn't give us any way to correlate the two values. Knowing that
there is a library cycle with M libraries and a cycle with N lines of
code, doesn't tell us whether it's the same library cycle in both cases.
Still, I think it will help us understand the nature of the code that
we need to be able to analyze quickly.
Change-Id: I36a8bf11c4c6fdced6c524225be7a633062351ac
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/437126
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
E.g. when sending 2000 results to a completion request, sending (json
and utf8 encoding) can be a very big part of the cost and it's very
confusing having it attributed to "self" in "request".
Also `mapSuggestions` looked much cheaper than it was because it used
`run` instead of `runAsync`.
Change-Id: Ifd219adb25fa658930548536eb8eb46276acd4a2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/436922
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
With this change, CreateMethodOrFunction complies with the contract
that `fixKind` not change before/after `compute()` is called.
This change includes some tidying to simplify the code:
* The decision of whether to use `DartFixKind.CREATE_METHOD` or
`DartFixKind.CREATE_FUNCTION` is solely based on whether the
"target element" is an InterfaceElement. So in the new factory
constructor, we compute the "target element", and save that in a
final field, as well as the fixKind.
* `isStatic` was computed eagerly with other variables in a nest of
else-if bodies. But it is only needed when creating a _method_, and
so it's value can be computed nearer to where it is used.
* `compute()` was ~100 lines long, and a lot of that code was dedicated
to computing the parameter type. Intermediate values like `argument`
and `parameterElement` sort of clutter the local variables; all of
that code can be moved to a function that just computes the
parameter type.
Change-Id: Ibd5d96b752e7e03e52f585bb594c34331b08cdf1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/436861
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Work towards #60635
In this change, we rework the AnalysisErrorListener deprecation to
better support users who have their own class that implements
AnalysisErrorListener. This change introduces a sealed supertype,
DiagnosticOrErrorListener, with the old implementation,
AnalysisErrorListener, and the new implementation, DiagnosticListener,
as its sole direct subclasses. Users who have implemented
AnalysisErrorListener should be able to instead implement
DiagnosticListener, and their class is an acceptable instance of
DiagnosticOrErrorListener, wherever that is needed.
In a breaking change we can drop AnalysisErrorListener and deprecate
DiagnosticOrErrorListener, and in the next breaking change, we can drop
DiagnosticOrErrorListener.
For reference, see the first API difference when deprecating AnalysisErrorListener and introducing DiagnosticListener: https://github.com/dart-lang/sdk/commit/903d77cc8229972a424941dcb7b7b79741e833eb#diff-dec15868961d7eadcd009f49d129bebcdb747aaa8dbfde5f5a08884e0cf11e32
Change-Id: I3ccf11d54b41fbca98d020d89978d250c16b4c04
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/436480
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
The "add late" assist was broadened in
https://dart-review.googlesource.com/c/sdk/+/176900 with a link to
https://github.com/dart-lang/sdk/issues/44440 where the example is
adding `late` to a field in the same class the user is currently editing
the constructor for.
That makes sense.
The code could also add the `late` keyword to other files which is - I
think - bad for at least two reasons:
1) It's confusing being given the option to "add late" to something,
then when trying it nothing seemingly happen, except something does
happen: another - possibly not open - file has changed.
2) It requests the resolved unit for another - possibly not open -
file, which is slow. This means that, at least in VSCode, just
moving the cursor over something can send requests that takes a
long time. In practise I've experienced up to ~1.5 seconds, and in
benchmarks I can make this arbitrarily large by increasing the
size of the file. Shown below, having 16,000 small classes takes
around 4 seconds (vs less than 10 ms with this CL).
This CL restricts this to the same file, adds a few tests and updates
a few existing tests.
Note that the existing tests that verified the behavior of adding `late`
to other files was added in
https://dart-review.googlesource.com/c/sdk/+/180087 with a link to
https://github.com/dart-lang/sdk/issues/44534
where the issue discusses a bug where it is applied in the wrong file
and says that it should either be applied to the right file or be
disallowed. The option of allowing it was picked in that instance,
but now at least there's data to show that it comes at a cost.
For an ad-hoc test where I programmatically asks for assists at every
position in `pkg/front_end/lib/src/kernel/body_builder.dart` I go from
1875 positions that takes >= 100 ms to answer to 0 such positions.
For the added benchmark I get this data:
Before this CL:
```
size 1000:
Initial analysis: 0.188291
Action call on 4:11 : 0.308514
Action call on 4:12 : 0.319540
Action call on 4:13 : 0.274678
peak virtual memory size: 2363 MB
total program size (virtual): 2292 MB
peak resident set size ("high water mark"): 258 MB
size of memory portions (rss): 244 MB
size 2000:
Initial analysis: 0.387643
Action call on 4:11 : 0.649877
Action call on 4:12 : 0.550778
Action call on 4:13 : 0.474030
peak virtual memory size: 2325 MB
total program size (virtual): 2325 MB
peak resident set size ("high water mark"): 279 MB
size of memory portions (rss): 277 MB
size 4000:
Initial analysis: 0.753913
Action call on 4:11 : 1.086648
Action call on 4:12 : 1.015921
Action call on 4:13 : 0.915511
peak virtual memory size: 2335 MB
total program size (virtual): 2304 MB
peak resident set size ("high water mark"): 363 MB
size of memory portions (rss): 334 MB
size 8000:
Initial analysis: 1.235531
Action call on 4:11 : 1.880335
Action call on 4:12 : 1.824658
Action call on 4:13 : 1.771081
peak virtual memory size: 2414 MB
total program size (virtual): 2386 MB
peak resident set size ("high water mark"): 436 MB
size of memory portions (rss): 411 MB
size 16000:
Initial analysis: 2.618666
Action call on 4:11 : 3.991542
Action call on 4:12 : 3.775863
Action call on 4:13 : 4.094692
peak virtual memory size: 2576 MB
total program size (virtual): 2516 MB
peak resident set size ("high water mark"): 667 MB
size of memory portions (rss): 611 MB
```
With this CL:
```
size 1000:
Initial analysis: 0.202665
Action call on 4:11 : 0.005730
Action call on 4:12 : 0.003086
Action call on 4:13 : 0.002743
peak virtual memory size: 2174 MB
total program size (virtual): 2170 MB
peak resident set size ("high water mark"): 256 MB
size of memory portions (rss): 247 MB
size 2000:
Initial analysis: 0.433420
Action call on 4:11 : 0.005353
Action call on 4:12 : 0.002116
Action call on 4:13 : 0.002156
peak virtual memory size: 2226 MB
total program size (virtual): 2226 MB
peak resident set size ("high water mark"): 290 MB
size of memory portions (rss): 240 MB
size 4000:
Initial analysis: 0.674376
Action call on 4:11 : 0.004219
Action call on 4:12 : 0.002138
Action call on 4:13 : 0.001625
peak virtual memory size: 2392 MB
total program size (virtual): 2328 MB
peak resident set size ("high water mark"): 306 MB
size of memory portions (rss): 286 MB
size 8000:
Initial analysis: 1.244688
Action call on 4:11 : 0.005225
Action call on 4:12 : 0.002104
Action call on 4:13 : 0.002729
peak virtual memory size: 2349 MB
total program size (virtual): 2338 MB
peak resident set size ("high water mark"): 385 MB
size of memory portions (rss): 366 MB
size 16000:
Initial analysis: 2.776680
Action call on 4:11 : 0.008848
Action call on 4:12 : 0.002854
Action call on 4:13 : 0.002327
peak virtual memory size: 2423 MB
total program size (virtual): 2405 MB
peak resident set size ("high water mark"): 505 MB
size of memory portions (rss): 489 MB
```
It's interesting how the action calls for sizes >= 4000 was slower than
the initial analysis, but I haven't looked into it.
Change-Id: Icefe02073cdf1ad442a37de2030fd7e53f5013b9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/436280
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
This request is useful only for elements. We can create a synthetic
element, and by necessity a fragment for it, but we never create a
synthetic fragment just by itself, for a non-synthetic element.
Change-Id: Ia8fee5e12e7b2c915c72276a402e164b9b30dc1e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/436080
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
There was only one place that wasn't using a future with a zero length
duration, but that's now been fixed. I haven't been able to observe any
performance improvement from this change, but it does have the benefit
that the code is now consistent.
Change-Id: I232728ef2ef9a1000938d0117f611a96c17e9f38
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/435662
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
Replace `getInheritedMap()` with v2 version.
Remove `getMember()`, operations should go thought elements, not types.
Remove `getMember2()`.
Rename v2 `getMember4()` into `getMember()`.
A few internal methods are duplicated for now, will be de-duplicated
when migration of InheritanceManager3 is finished. For now I'd like to
do smaller steps than migrating it fully.
Change-Id: Ib5d9d28e91d77330e41480fcb7176f93d867728a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/435663
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Main changes:
1. Separating `FragmentBuilder` and `ElementBuilder`. I removed
`augmentation.dart` and its builders, because now it is implemented in
the new `ElementBuilder`.
2. Fragments are not given actual `Reference` objects anymore, there
might be some in the current state, but I will go over this in the
future and remove them completely.
3. Writing and reading elements also happens in two stages: first
fragments, then elements. Each fragment in the summary is given unique
ID, and during writing / reading elements we use these ID to locate
fragments and create elements around them.
4. Lazy loading of `ClassElement` members is simplified and generalized,
could be potentially applied to any `InstanceElement`. Maybe use also in
mixins, which are used somewhat often in Flutter.
5. There are slight changes to tests, mostly to the better, sometime a
bit reordering, a couple of new tests.
There is some dirty code added, especially around patching types for
getters, setters, and their fragments. I plan to clean this in future
CLs as I move toward better implementation, and from using fragments
where this is wrong.
Change-Id: I1e4bf2a3b7ff45f1dba133797e85cd70aa729c11
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/433180
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Code completion for property accesses.
When typing `.`, code completion will suggest static members based on the context type at that location.
Added unit tests with and without prefixes.
I'll follow up with additional tests and changes for invocations. I wanted to make sure I wasn't missing anything here.
Bug: https://github.com/dart-lang/sdk/issues/59836
Change-Id: Ib488bd02cdc66bacd6fa527b983a215f2e16b442
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/434144
Commit-Queue: Kallen Tu <kallentu@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This was mostly a rename/move of the folder (and the analysis server updated all references), but I also had to:
- add `integration_test/analysis_options.yaml` to import from `../test` to get the same lint ignores
- update paths of exclusions in `verify_sorted_test.dart`
By moving all of the tests that start the server out-of-process out of test, we can:
1. Use "dart test" to just run the faster tests ("dart test test") and get functionality of the pkg:test runner (for example running tests concurrently and JSON output)
2. Allow VS Code to spawn different debug sessions for the "test" and "integration_test" folder, which means we can use a `preLaunchTask` to trigger compilation of the analysis server from source whenever running integration tests (avoiding having to compile manually, or run from source in a way that compiles a new server for each test suite)
Change-Id: I37cc03dc32d08c5b51a2eab79f6338bb079b32ac
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/434801
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Before this CL (introduced in 816b974c15)
every file was attempted fetched as a dart file when collecting a report
and when opening the "context" page - so if you had other files, say,
several 100MB+ text files from the the computer language benchmarks
game, it would both take quite a while and eat up a good chunk of
memory.
This filteres to only dart files (as it's done in other places that
calls `contextRoot.analyzedFiles()`) but leaves the functionality.
As for the functionality, while I understand that the information can be
useful it potentially force-loads a lot of data (even if only actual
dart files) which I'm not sure is a good idea. A happy user likely won't
visit this page, and an unhappy user is probably not getting any happier
by the memory usage increasing. Anyway. Food for thought.
Change-Id: I0c9f690b9b275cb1970920cdb55e14b1a1429aa4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/434700
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
An earlier CL fixed a bug where an inline-method refactor could be
initiated at a reference to a top-level function in an import
combinator.
This CL makes the corresponding change to prevent such references from
being changed when the refactor is initiated at the declaration site.
Change-Id: I769ff83ce946d971780474a9908e1ac63bd1e02d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/434180
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Konstantin Shcheglov