Before an assist call on a file with non-windows lineendings would first
search through the entire file for Windows line endings, then search for
the non-Windows line endings. As such Windows line endings was faster.
This CL changes the semantics slightly from "Windows line endings if
any Windows line endings exist" to "whatever line endings are first
used" which should be good.
It speeds up assist calls with non-Windows line endings:
Statistics on 5 runs each:
```
Windows / 2000: No change.
Windows / 4000: No change.
Windows / 8000: No change.
Unix / 2000: 1000 assist calls: -46.9900% +/- 6.1715% (-0.88 +/- 0.12) (1.86 -> 0.99)
Unix / 4000: 1000 assist calls: -59.1561% +/- 6.3982% (-1.79 +/- 0.19) (3.03 -> 1.24)
Unix / 8000: 1000 assist calls: -63.8429% +/- 4.3083% (-3.68 +/- 0.25)(5.76 -> 2.08)
```
Change-Id: I61278ed4ad31b891e87951da0a6162fe37376888
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/437224
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Jens Johansen <jensj@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>
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>
The TEST_SERVER_SNAPSHOT env variable could previously be set to the string "false" to indicate not running the tests using the server snapshot (in which case, we'll instead compile the snapshot to a temp location and then use that).
This worked well for running the tests via `test_all.dart` where all tests run in a single isolate and share a single compilation. However it doesn't work well through `dart test` (which the VS Code test runner will use so we can get the results in JSON and populate the test tree) because each test runs in its own isolate and therefore still triggered compilation for every test.
This expands the `TEST_SERVER_SNAPSHOT` env variable to also support passing another string, which is a path. If provided, this path is used as the snapshot instead (with no compilation).
With a small amount of configuration for Dart-Code (which will be documented and/or committed into the `.vscode/` folder here), this will allow Dart-Code to compile the snapshot when running integration tests, and then trigger `dart test` with the env var set, meaning all integration tests across all isolates will share the same compilation.
The goal is to be able to make changes to the server and seamlessly run the integration tests from the editor without having to remember to run any external compilation (and for the integration tests to not take 17 minutes).
Change-Id: Ia2ef13da8d9a4debe9fa2c8016ef021f6abed8b5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/434800
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
When running analysis server tests from source, we now (since a recent change) pre-compile the server to avoid compilation on every test.
If the first test run was `test\integration\analysis\get_errors_non_standard_sdk_test.dart` we would try to compile with the non-standard (and incomplete) SDK created by the test, and fail because of https://github.com/dart-lang/sdk/issues/52752. This changes to always use the real SDK that we're running with for the compilation instead.
Change-Id: I1028c24ecb18f9caa465b579866d07a72c1dc02b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/433822
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: 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>
When working on the analysis server, you can set the `TEST_SERVER_SNAPSHOT` env var to `false` to spawn the server from source (`bin/server.dart`) instead of running the snapshot, which allows easily running the integration tests (which spawn the server in a separate process) from the IDE without having to run (and wait for) builds.
However running from source like this can be quite slow because every test that spawns the server results in it being compiled on-the-fly. This change instead uses `dart compile` to compile the server from source to a temp file the first time we return the path, and then subsequently returns the same path.
On my Windows PC, this reduces the time to run the integration tests (with the env variable set) from 17min to 2min.
Change-Id: I612d1a978d22d214dc086962d8c9eb2e7dfe8239
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/434080
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This removes `useLineEndingsForPlatform=false` from the Snippets tests and updates them to use a shared method that correctly handles normalization of the `expected` result.
It turned out that we had bugs here, with the correct line endings not being used, so it also fixes that by passing `eol` to the `ChangeBuilder`s created by the snippet producers.
Progress towards https://github.com/dart-lang/sdk/issues/60234
Change-Id: I851fee987dda52f329d110878e10593cbced8c6c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/433780
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
There are no semantic changes in this CL, just renames.
The one unfortunate rename was from `DEFAULT` to `default_`. It can't be
`default` because that's a built-in identifier. If you have a better
convention to follow here I'm happy to change it.
Change-Id: Idf70621ad577dbea6c1c161aac17e9e200aac2d0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/433440
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
The related issue asked for a new priority for the `Create class` fix
that would be lower if the undefined name was lowercase, giving the
`Create method` and `Create function` fixes a higher relative priority.
This change also adds a new abstract class to test the relative priority
between fix kinds. It is also used to test agains the merge combinators
fixes.
Fixes: https://github.com/dart-lang/sdk/issues/60523
Change-Id: I938f52a577ecf1b6bb8dd66c94fd45395a011ffa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/422321
Auto-Submit: Felipe Morschel <git@fmorschel.dev>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
This disables the assist if the field formal parameter happens to also
be an older style function typed parameter. As written the assist
produces invalid code, and the older style is strongly discouraged so
not supporting it shouldn't impact very many users.
Change-Id: I44a3942b4656265bb1cbbba29e68fff61962b689
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/433260
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
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 prevents inline values showing up alongside code that didn't execute in conditional blocks. It does also mean they don't know up in conditional blocks that _did_ execute one execution has fallen out of them, but I believe this is the best we can do with the current LSP APIs (unless we try to track execution across requests, but that would probably be complete and not entirely reliable).
Fixes https://github.com/Dart-Code/Dart-Code/issues/5454
Change-Id: Ia1cf2437b76844ff0a6aeeb958d769c9523dc5dd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/433200
Commit-Queue: Keerti Parthasarathy <keertip@google.com>
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This is a partial revert of ca9523058e (it removes the behaviour change and the test that verifies this, but leaves two additional tests that were added relating to roots that are created later).
If we rebuild contexts when a root is deleted, we may get stuck in a loop because we will again try to recreate the same (deleted) root, and then the watcher will close in a way that looks like a deleted folder, and we will repeat.
Fixes https://github.com/dart-lang/sdk/issues/60863
Change-Id: I10289160b341d273e8e409184a1c013c7fb9439d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/433140
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Jens Johansen