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>
We take any `<tt>`-wrapped text, and keep it in some "monospaced" /
"teletype" format. For dartdoc we put it in backticks. For Javadoc
we put it in `<code></code>`, which looks standard for inline text.
This corrects some erroneous doc comment reference-looking text
(`offsets[i]`) which is not meant to be a doc comment.
Change-Id: I1d77a02368e3cde158ce95d3b0095ba09e071370
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/401340
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
This code generation was previously formatting generated files using the latest version. In 76feb10829 I re-ran the formatter to get the new formatting style.
However recently, a pre-submit hook to verify formatting was enabled and revealed that pkg:language_server_protocol still has an older SDK constraint, so the presubmit fails (if you modify these files).
There are two options:
1. Restore formatting to the previous version for pkg:language_server_protocol
2. Increase the SDK constraint for pkg:language_server_protocol
I picked the first for now, since analyzer_server_plugin also depends on pkg:language_server_protocol and currently has a constraint of 3.3, and I don't want to mess with that just to fix the format presubmit.
Change-Id: I2347577561e659825b444ef6622d646c6e513aea
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/401001
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
This change is the final piece in enabling plugins in the new style to
be launched from a specification in analysis options.
Work towards https://github.com/dart-lang/sdk/issues/53402
* We support both one legacy analyzer plugin (the current max), and
a set of new analyzer plugins, which are combined and launched in one
shared plugin isolate.
* Make PluginLocator.pluginMap private.
* Add a parameter to PluginManager.addPluginToContextRoot:
isLegacyPlugin. This method is used for both legacy and new plugins,
but has slightly different behavior, finding where the plugin files
are.
Change-Id: I6644aecd4283eea22586ffd051a01b0ec8987fc5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/395360
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
This adds basic editing for the argument types supported by `textDocument/editableArguments`. It doesn't currently attempt to format code currently (or use multiline/raw strings where they might be more appropriate), and does not allow arbitrary values that don't match the type for the parameter.
Change-Id: Ied95d95c0de39310aef0a1153864e902d56e1910
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/395280
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Elliott Brooks <elliottbrooks@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Some minor fixes/tweaks extracted from another CL
1. Fix tool/lsp_spec/codegen_dart to set `options` on `CodeStyleOptions` (a late field that needs to be set to the owning options file)
2. Fix a wrapped TODO to be indented so it's detected correctly
3. Move the custom `DartTextDocumentContentProviderHandler` handler into the `custom` folder
4. Merge `LspHandlerHelperMixin ` into `HandlerHelperMixin` since the APIs it uses are no longer LSP-specific and exist on the base server
Change-Id: Ie1b3a8057575346cf9bfb98465c0a3e330c28a82
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/392909
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Phil Quitslund <pquitslund@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Danny Tuppeny