There are a few things in this CL that were difficult to separate testing of (because they're all part of the same feature):
1. sets `requiresTrustedCaller=false` on the `executeCommand` handler so that commands can be called over DTD. It adds the same flag to the command handlers themselves, so a command can control whether it can be called over DTD or not (right now we allow everything except `logAction` and `sendWorkspaceEdit` which are both commands used internally and not appropriate for DTD clients to call).
2. Removes the allow-list on DTD methods, allowing all LSP shared methods to be available over DTD
3. Extends the integration test classes to support reverse-requests so we can verify the edits being sent back to the editor when calling the code actions commands over DTD
4. It also fixes a few bugs where we read the callers capabilities instead of the editors capabilities (which until now would always be the same in those places, but with this change are not).
Change-Id: I6d271ddad6dc1b00a98b10b735763a368c91af7a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/428784
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This adds an optional version number to AddContentOverlay and UpdateContentOverlay in the legacy protocol.
It also moves some code (such as the `Map` that stores the current document versions) from the LSP server into the base class, and updates the overlay handlers to update it.
And finally, it removes the FailingTest() annotations on the versioned EditArguments test since they now work.
Change-Id: Icf2a2825eb6227f5faa3e21ae6c3a7d15997ef5a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/404821
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
By changing a benchmark to say
```
LaunchFrom get launchFrom => LaunchFrom.AotWithPerf;
```
and compiling the server with aot:
```
out/ReleaseX64/dart-sdk/bin/dart compile aot-snapshot pkg/analysis_server/bin/server.dart
```
running the benchmark will run from the aot snapshot and automatically
launch `perf`, allowing one to do `perf report` after to get a profile
of the entire benchmark.
Change-Id: Idd5c576129acaf4756befb22f9832b24f93b1583
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/426480
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
I wrote a test that generates 10,000 lines of code, each containing one
violation of `prefer_single_quotes`, computes the fixes for all of the
diagnostics, and applies the 20,000 edits, measuring how long the
application takes.
Before this change the average was 3355.0 ms.
After this change the average is 3.8 ms.
The change was inspired by Jens.
Change-Id: Icd54a81ca3848fd5f0168934f713a7be8caec359
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/425601
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
For the select all one I get
50: 0.310976 seconds
100: 1.054733 seconds
200: 5.535353 seconds
400: 36.099675 seconds
800: 247.919461 seconds
Disabling that (so I can go higher) for the
"Subsequent action call 1" (simulating moving the cursor down a line
in the IDE in the file) I get
100: 0.047451 seconds
200: 0.079821 seconds
400: 0.160073 seconds
800: 0.451288 seconds
1600: 1.311321 seconds
3200: 5.549266 seconds
6400: 32.955526 seconds
Note that for all of this it's just a single file with <size> lines
looking like
```
"num": "num",
```
so even though 6400 is a "large number" it's not entirely unrealistic.
Change-Id: I5c2a51822c0748b4a71d98cef9caeb3e30aec5bc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/425503
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
The term "CodeAction" is a bit overloaded. It could mean both an
individual result from the `textDocument/codeAction` request (which is a
`Command` or a `CodeAction`), or the `CodeAction` type defined in
the spec (which the spec refers to as a "Code Action literal").
To reduce confusion where we have similar APIs that operate on
"Code Actions" (CodeAction|Command), this renames the `CodeAction` class to
`CodeActionLiteral` and we will use the term `CodeAction` to mean either of
those types.
To make things simpler to review, this change _only_ renames the class, and also swaps the order of the types in some places that used `Either2<Command, CodeAction>` (which is opposite to the spec and some other code). Some further clean up will be done in a separate change.
Change-Id: Idcd8265f9229c3450004e68334e98a7b530330a4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/425300
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
TL;DR: Add benchmark that shows the Dart 3.7
(https://dart-review.googlesource.com/c/sdk/+/386581 specifically)
introduced a regression.
Details: We've observed that sometimes the plugin that users has
installed times out (takes > 500 ms to answer).
This benchmark simulates that and shows the worse handling of this
introduced in Dart 3.7.
Running 10 iterations each of lsp_with_plugin_that_times_out.dart with
params 10, ImportChain:
Comparing 3.5.4 with 3.6.2
```
Initial analysis: -7.1855% +/- 2.9168% (-0.09 +/- 0.04)
peak virtual memory size: 11.8795% +/- 1.6185% (313.00 +/- 42.64)
total program size (virtual): 12.4293% +/- 1.2818% (323.10 +/- 33.32)
peak resident set size ("high water mark"): -7.4081% +/- 0.9050% (-38.90 +/- 4.75)
size of memory portions (rss): -6.3154% +/- 1.3641% (-32.00 +/- 6.91)
```
I'll note that this is only 10 files and we probably shouldn't put too
much weight on the initial analysis time here. Equivalently memory
probably isn't super interesting.
Comparing 3.6.2 with 3.7.2
```
Initial analysis: -45.8697% +/- 2.7193% (-0.53 +/- 0.03)
Completion call 1: 652.8573% +/- 1.3303% (0.97 +/- 0.00)
codeAction call 1: -0.7637% +/- 0.5174% (-0.01 +/- 0.01)
Completion call 2: 807.2503% +/- 0.7116% (0.89 +/- 0.00)
codeAction call 2: 0.2624% +/- 0.0456% (0.00 +/- 0.00)
Completion call 3: 868.9361% +/- 0.3199% (0.90 +/- 0.00)
codeAction call 3: 0.1433% +/- 0.0287% (0.00 +/- 0.00)
peak virtual memory size: -7.1307% +/- 3.4799% (-210.20 +/- 102.58)
total program size (virtual): -8.1674% +/- 3.5673% (-238.70 +/- 104.26)
peak resident set size ("high water mark"): -1.2546% +/- 0.7151% (-6.10 +/- 3.48)
size of memory portions (rss): -7.6891% +/- 0.9209% (-36.50 +/- 4.37)
```
Again I'll note that this is only 10 files and we probably shouldn't put
too much weight on the initial analysis time here - although we've seen
this improve in other benchmarks too so I do believe we have an
improvement here.
And again memory probably isn't super interesting because of the few
files.
The codeAction calls are basically the same which makes sense: In all
cases it's dominated by the plugin that times out.
The codeAction call does two calls to the plugin and it takes around
1000 ms (a timeout of 500 ms on each plugin call).
Here we see the regression in 3.7 clearly though (cut-out from above):
```
Completion call 1: 652.8573% +/- 1.3303% (0.97 +/- 0.00)
Completion call 2: 807.2503% +/- 0.7116% (0.89 +/- 0.00)
Completion call 3: 868.9361% +/- 0.3199% (0.90 +/- 0.00)
```
Because of https://dart-review.googlesource.com/c/sdk/+/386581 we only
do one request at a time. Before we would interleave the requests,
something like this:
```
Request 1: codeAction:
|--|waiting for plugin|--|waiting for plugin|--|
Request 2: completion:
|..--|
```
(I'm trying to ascii-draw that when the codeAction is just awaiting the
plugin the completion request can be executed)
Now instead we're doing this:
```
Request 1: codeAction:
|--|waiting for plugin|--|waiting for plugin|--|
Request 2: completion:
|..............................................--|
```
(I'm trying to ascii-draw that when the codeAction has to finish before
the completion request can be executed)
I'll also note that while it's here shown trough a plugin that times out
the same will likely happen in other circumstances as well. E.g. the
completion resolves with a special call `resolveForCompletion` which in
`performWork` gets priority over other things - but when not
interleaving requests that has very little effect.
For good measure, comparing 3.7.2 with HEAD
```
Completion call 1: 0.6851% +/- 0.2074% (0.01 +/- 0.00)
codeAction call 1: 0.6962% +/- 0.1876% (0.01 +/- 0.00)
peak virtual memory size: -11.7293% +/- 4.7947% (-321.10 +/- 131.26)
total program size (virtual): -12.1763% +/- 4.9125% (-326.80 +/- 131.85)
peak resident set size ("high water mark"): -14.7469% +/- 0.6980% (-70.80 +/- 3.35)
size of memory portions (rss): -10.4518% +/- 0.8927% (-45.80 +/- 3.91)
```
Not a whole lot of change for the time-related things on this benchmark.
Running legacy_with_plugin_that_times_out.dart shows the same thing
(here there's only 1 plugin call instead of 2 though; here only looking
at completion calls):
```
Comparing 3.5.4 with 3.6.2
Completion call 1: -6.1695% +/- 3.6147% (-0.03 +/- 0.02)
Completion call 2: -14.4462% +/- 8.8828% (-0.02 +/- 0.01)
Completion call 3: -16.7707% +/- 7.5412% (-0.03 +/- 0.01)
Comparing 3.6.2 with 3.7.2
Completion call 1: 139.2436% +/- 3.8814% (0.70 +/- 0.02)
Completion call 2: 1128.6580% +/- 14.8207% (1.41 +/- 0.02)
Completion call 3: 589.1425% +/- 11.9186% (0.78 +/- 0.02)
Comparing 3.7.2 with HEAD
no change on completion calls.
```
For fun, lets try to comment out `await completer.future;` in
`pkg/analysis_server/lib/src/server/message_scheduler.dart` that was
introduced in https://dart-review.googlesource.com/c/sdk/+/386581
(again only looking at completion calls):
legacy_with_plugin_that_times_out.dart:
```
Comparing 3.7.2 with HEAD (with commented out await)
Completion call 1: -58.5720% +/- 1.9196% (-0.70 +/- 0.02)
Completion call 2: -82.8149% +/- 1.1050% (-1.27 +/- 0.02)
Completion call 3: -85.6439% +/- 1.5128% (-0.79 +/- 0.01)
```
If looking at the values instead of the percent it looks to almost undo
the change from 3.6.2 to 3.7.2, so let's for good measure compare 3.6.2
with that:
```
Comparing 3.6.2 with HEAD (with commented out await)
Completion call 2: 95.7654% +/- 11.4279% (0.12 +/- 0.01)
```
So one of the calls is slower, but just double, not 10x. I haven't
looked into why.
And for lsp_with_plugin_that_times_out.dart:
```
Comparing 3.7.2 with HEAD (with commented out await)
Completion call 1: -92.9578% +/- 0.5505% (-1.04 +/- 0.01)
Completion call 2: -99.6372% +/- 0.0534% (-1.00 +/- 0.00)
Completion call 3: -99.6370% +/- 0.0429% (-1.00 +/- 0.00)
```
The 1000 ms wait time is gone.
And again let's for good measure compare 3.6.2 with that:
```
Comparing 3.6.2 with HEAD (with commented out await)
Completion call 1: -45.4578% +/- 2.4320% (-0.07 +/- 0.00)
Completion call 2: -96.6303% +/- 0.2481% (-0.11 +/- 0.00)
Completion call 3: -96.2054% +/- 0.3875% (-0.10 +/- 0.00)
```
Here all the completion calls are faster. I haven't looked into why.
Change-Id: I7c312f77b51bb4df68eedeb9bc6e27c2b0175cbf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/418263
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
This CL adds the option of sending arguments to the benchmark(s)
* Specify what dart to use (e.g. `--dart=/path/to/dart-sdk/bin/dart`),
e.g. if wanting to run benchmarks on an (old) released version.
* Specify the number of files to operate on (e.g. `--files=100,200`).
* Specify the code-types to benchmark
(e.g. `--types=ImportChain,ImportExportChain`)
* Specify verbosity, e.g. to debug (maybe `--verbosity=4`) or to run
benchmarks several times only to look at the final result
(`--verbosity=-1`).
Change-Id: I5c731f3e6480afdff0546a29c599430d2ab6e7be
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/417460
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Get memory info on Linux from the proc filesystem
(`/proc/<pid>/status`).
E.g.
```
Initial analysis: 2.600716
Completion after change: 0.783488
peak virtual memory size: 2288 MB
total program size (virtual): 2235 MB
peak resident set size ("high water mark"): 302 MB
size of memory portions (rss): 257 MB
```
Change-Id: I3c16d00569d6427627a8629c465e85a15f962c32
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/417162
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Recently a bug was fixed in the formatter, regarding how declarations
preceded by an end-of-line comment are formatted. Good to just bundle
the formatting changes into one CL.
Change-Id: Ieab8ec3263932505f8b8da77fbe637dffc61b46d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/417040
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
This lint rule is a core lint rule; we have suppressed it only for
pre-existing code reasons.
There are a few individual files which simply have a consistent pattern
of including underscores in some names, so I add inline ignores there.
Change-Id: I89e6010203868fc10fda12b15353de41881d9b15
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/416900
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
*TL;DR*
This improves scanner recovery for a missing `}` in certain situations,
reducing the risk of an in-body change causing a (temporary) outline
change (which in turn could result in the analyzer becoming unresponsive
for "no reason").
*Details*
The behavior of IntelliJ is that when typing `{` it only inserts a
matching end brace `}` when hitting enter.
Imagine you are typing an if: `if (1 + 1 == 2) {`, where you don't hit
enter quickly enough and you trigger a re-analysis at this point.
What happens then is that every method below where you are typing looks
to be local function declarations and thus the outline change. When the
outline change the analyzer has to do a lot of work: everything
(transitively) depending on the file has to be recompiled, and every
strongly connected component is compiled "in one go" where the analyzer
can't respond to queries. So if you have one or more large strongly
connected components depending on the file, or the file itself is part
of such a chain, you will (or at least might) experience that the
analyzer is slow to respond, and it will be extra puzzling because
logically you're just doing an in-body change.
For some code the user might not even naturally hit enter, e.g. `var foo
= {"I'm", "a", "set"};`.
The recovery in the scanner has always been that - upon reaching the end
of the file - it sees that we're missing a `}` and it inserts it at the
end. This CL instead tries to figure out a better place to insert it,
and if successful, will rerun the scanner, instructing it to insert it
at the better place and (hopefully) avoiding a subsequent outline
change.
It does this by looking at the indentation - which is new for recovery -
and under the assumption that the indentation was correct before, will
find the position where the start curly brace was inserted. Note that if
it finds a position it will always be between the start curly brace (the
one missing the end curly brace) and the end of file, and inserting the
missing curly end brace there can't really be "more wrong" than
inserting it at the end (if the new place is not correct it's just
"still wrong").
In the benchmark added we see how quickly we can get completion after
having typed `if (1+1==2) {`, then adding `\n ge\n}` and requesting
completion on the `ge` part, i.e. a simulation of typing
```
if (1+1==2) {
ge
}
```
and asking for completion at the `ge`.
The change in this CL - on cycles of size 1024 - caused the time to
completion response to come in between ~5 times faster (going from ~10.2
to ~2.1 seconds) to ~18 times faster (going from ~10.3 seconds to ~0.56
seconds):
`CodeType.ImportExportCycle` goes from:
```
+------+-----------+------------+
| Size | Initial | Completion |
+------+-----------+------------+
| 16 | 2.019581 | 0.97504 |
| 32 | 3.028976 | 1.031008 |
| 64 | 4.422884 | 1.198383 |
| 128 | 7.612125 | 1.597091 |
| 256 | 12.860864 | 2.906553 |
| 512 | 24.391894 | 5.017093 |
| 1024 | 48.390993 | 10.243085 |
+------+-----------+------------+
```
to
```
+------+-----------+------------+
| Size | Initial | Completion |
+------+-----------+------------+
| 16 | 2.107213 | 0.661066 |
| 32 | 3.012952 | 0.70554 |
| 64 | 4.682508 | 0.731176 |
| 128 | 7.508434 | 0.745501 |
| 256 | 13.105477 | 0.852413 |
| 512 | 24.520184 | 1.278403 |
| 1024 | 48.804348 | 2.11903 |
+------+-----------+------------+
```
and `CodeType.ImportExportChain` goes from:
```
+------+-----------+------------+
| Size | Initial | Completion |
+------+-----------+------------+
| 16 | 2.059196 | 0.892082 |
| 32 | 3.080717 | 0.93232 |
| 64 | 4.647163 | 1.240303 |
| 128 | 7.377035 | 1.674859 |
| 256 | 12.939432 | 2.705483 |
| 512 | 24.529501 | 5.02689 |
| 1024 | 47.713553 | 10.385469 |
+------+-----------+------------+
```
to
```
+------+-----------+------------+
| Size | Initial | Completion |
+------+-----------+------------+
| 16 | 2.020809 | 0.709643 |
| 32 | 3.106856 | 0.648818 |
| 64 | 4.503067 | 0.593152 |
| 128 | 7.45692 | 0.622423 |
| 256 | 13.140592 | 0.606948 |
| 512 | 24.933216 | 0.612687 |
| 1024 | 50.167541 | 0.567544 |
+------+-----------+------------+
```
Change-Id: I8dbefe215162d00a209206ae3db83b2b17505853
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/415581
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
This is required so that an analyzer plugin can process producer generators that are registered in a plugin isolate.
* Change `AssistProcessor._generators` and
`AssistProcessor._multiGenerators` into private top-level variables
which are only used as "built-in" assist processor generators. They
must be explicitly registered, which we see much of in this change.
* Rename all of the lists of _generators_ and maps with lists of
_generators_, which were named "producers". The new names are
"generators." This leads to giant diffs because of alphabetizing.
Change-Id: Id4432737daaec1bb282f0b387619b23c18c0ea55
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/414665
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
In reports of the analyzer being slow we've seen `edit.getFixes` causing
a long queue because they take longer to execute than the wait before
the next one comes in.
While we haven't been able to reproduce that, this CL adds a benchmark
that fires *a lot* of both `edit.getFixes` (seen in reports from users)
and `edit.getAssists` (which seems, locally at least, to happen every
time the cursor moves), and debounces them, changing the benchmark
results from
```
4 files / CodeType.ImportCycle:
Initial analysis: 1.322030
Completion after change: 3.096128
4 files / CodeType.ImportChain:
Initial analysis: 1.361750
Completion after change: 3.500849
4 files / CodeType.ImportExportCycle:
Initial analysis: 1.349346
Completion after change: 3.065497
4 files / CodeType.ImportExportChain:
Initial analysis: 1.367151
Completion after change: 3.246891
4 files / CodeType.ImportCycleExportChain:
Initial analysis: 1.360573
Completion after change: 3.393901
```
to
```
4 files / CodeType.ImportCycle:
Initial analysis: 1.322070
Completion after change: 0.546532
4 files / CodeType.ImportChain:
Initial analysis: 1.410870
Completion after change: 0.649789
4 files / CodeType.ImportExportCycle:
Initial analysis: 1.349923
Completion after change: 0.741040
4 files / CodeType.ImportExportChain:
Initial analysis: 1.360396
Completion after change: 0.638332
4 files / CodeType.ImportCycleExportChain:
Initial analysis: 1.354682
Completion after change: 0.658086
```
Change-Id: Icb0423133726e02e08e204b1c59209264889f8a6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/413682
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Also add benchmark where lots of hover requests are fired,
mimicking IntelliJ behavior when holding ctrl and moving the mouse over
imports.
I'm getting these results on my machine:
```
4 files / CodeType.ImportCycle:
Initial analysis: 1.249438
Completion after change: 10.143719
4 files / CodeType.ImportChain:
Initial analysis: 1.367604
Completion after change: 9.936909
4 files / CodeType.ImportExportCycle:
Initial analysis: 1.233644
Completion after change: 10.011695
4 files / CodeType.ImportExportChain:
Initial analysis: 1.226382
Completion after change: 9.875991
4 files / CodeType.ImportCycleExportChain:
Initial analysis: 1.262932
Completion after change: 9.995607
```
notice the low number of files (in the chain*) or if it even is a chain
etc doesn't appear to change anything for the time it takes to become
responsive again.
Notice that in
https://github.com/dart-lang/sdk/issues/55281#issuecomment-2700500279 I
noticed that something similar happened for `edit.getFixes`, but I'm yet
to actually reproduce that.
Change-Id: Iff04124825c6ea2f759b4d048a0f2988709eaebf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/413981
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Since the benchmark has its own `analysis_options.yaml` file, the
files inside it are analyzed with default analysis options, meaning
that `TODO` comments inside the benchmark are now showing up in the
IDE, which is distracting when making edits to the analysis server.
Change-Id: I42b02da06d6754a26157bcf0c07b8d5c4b2ac31d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/414240
Auto-Submit: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
A benchmark that launches the dart analyzer server in language server
protocol mode and communicates with is as an IDE.
In this case the benchmark generates between 16 and 1024 copies of the
abstract scanner (to get a large amount of code) as well as imports and
exports all the files in cycles and/or chains; performs an edit,
requests completion and times initial startup (with no cache),
completion after change and when it's done analyzing after the change.
It does this in several modes than change the way the files are imported
and exported:
* ImportCycle where file1 imports file2 etc and the last file imports
file1. There are no exports.
* ImportChain where file1 imports file2 etc and the last file doesn't
import anything. There are no exports.
* ImportExportCycle where file1 imports and exports file2 etc and the
last file imports and exports file1.
* ImportExportChain where file1 imports and exports file2 etc and the
last file doesn't import or export anything.
* ImportCycleExportChain where file1 imports and exports file2 etc and
the last file imports file1 but doesn't export anything.
For ImportCycle, ImportChain and ImportExportChain things appear to
scale ~linear and - using AOT - have timeings in this ballpark (this is
specifically for ImportCycle):
+------+-----------+------------+------------+
| Size | Initial | Completion | Fully done |
+------+-----------+------------+------------+
| 16 | 0.46561 | 0.158765 | 0.40474 |
| 32 | 0.901167 | 0.268819 | 0.859874 |
| 64 | 1.657207 | 0.428747 | 1.488365 |
| 128 | 3.178606 | 0.843576 | 3.040237 |
| 256 | 6.015557 | 1.737661 | 6.010487 |
| 512 | 12.08567 | 2.979242 | 11.736878 |
| 1024 | 24.273368 | 6.101671 | 24.018495 |
+------+-----------+------------+------------+
For ImportExportCycle and ImportCycleExportChain it scales worse and
e.g. ImportExportCycle looks like this:
+------+-----------+------------+------------+
| Size | Initial | Completion | Fully done |
+------+-----------+------------+------------+
| 16 | 0.46673 | 0.169486 | 0.406448 |
| 32 | 0.875871 | 0.242876 | 0.85543 |
| 64 | 1.583077 | 0.465915 | 1.506953 |
| 128 | 3.198071 | 0.903894 | 3.09165 |
| 256 | 6.786677 | 2.149489 | 6.779569 |
| 512 | 17.346131 | 8.92149 | 17.971033 |
| 1024 | 63.358453 | 46.152089 | 65.401559 |
+------+-----------+------------+------------+
(In the tables 'Completion' is time until completion answers after a
top-level change and 'Fully done' is time until the analyzer stops
analyzing after a top-level change).
Change-Id: Id7214c0d6c14199f39c0c8a6a8b4941a0e575dc3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/413401
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
This adds support for LSP's "Inline Values" for variables and properties, allowing their values to be seen floating in the editor while stepping with a debugger without having to hover.
Including property access/getters may be useful too, but that can be added in a future CL (and perhaps initially behind a flag to get feedback, in case it turns out to bee too noisy).
Fixes https://github.com/dart-lang/sdk/issues/59891
Change-Id: I6305cfa9a7583c30500b90ee3b29852c82cc2494
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/412080
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Now that we have `defaultValue` against each argument, there was some redundancy here.
`isDefault` is redundant because if `hasArgument=false` it's always default, and if `hasArgument=true`, then `value` and `defaultValue` can be compared
When `hasArgument=false`, there's no value in duplicating `defaultValue` into `value`
Change-Id: I5cba055e56175565842efef815e08dd46e9ed36a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/406621
Reviewed-by: Elliott Brooks <elliottbrooks@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This adds a new field to the existing (legacy) setClientCapabilities parameters that accepts an LSP ClientCapabilities.
This will allow a legacy client to indicate that it supports things like the `workspace/applyEdit` reverse-request.
Change-Id: Ia3b75c701f1699c92f902e058daec4844ce664fa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/404106
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Commit-Queue: Phil Quitslund <pquitslund@google.com>
Parse errors for spec types were being reported twice - once by the containing object (in canParse()), and once by the nested canParse() call for the nested type.
This skips reporting the error for nested calls to a canParse() method, which will always report the error itself.
Change-Id: I03e4a9638fd6a3fc77eac918f6fd16def93327d6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/404105
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This moves completion resolution off `ElementLocation` onto the class recently created as `TypeHierarchyItemLocation`, which is now renamed to `ElementLocation2` and extracted to its own file.
Change-Id: I1f0b831ded7b08d6c09f97fcfd66f38f1dd4750e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/401021
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Konstantin Shcheglov