This does not remove the computation of available declarations. This CL
seemed big enough without that, so I (or someone else) can get that in
the next CL.
Change-Id: I67ab49b75c8a415ccfaef16c4e49a00026a6091f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/341160
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This should have been a small change to keep us in-sync with small changes so when there are bigger changes (LSP 3.18.0) the change is less noisy.
However, it turns out the meta model is built from the latest version always, so it includes 3.18.0 proposed features.
So this change not only regenerates the code with the latest spec, it also adds some handling to exclude any types (and methods) marked as proposed.
It also includes a few minor fixes to things like re-wrapping of comments where there are references.
So, it should still essentially be a non-functional change, but the CL isn't as small as planned because of the cleanup.
- The lsp_meta_model.json file is downloaded and not changes I've made
- The protocol_generated.dart file is the output of the code-gen
- All other files are changes I made manually
Change-Id: I6380f86848d2799cf94d58a419ace0bf0d5a35ef
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/340040
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This may seem to be a silly change, adding these lists only for the
error fix status file, but I claim this is a very pragmatic solution:
* It is important and beneficial to correctly track error fix
statuses; I was recently confused about these fix statuses because
the text in the fix status file was a lie.
* When fixes are added for more errors, you cannot forget to update
the codesWithFixes list because the fix won't apply (and no test
asserting the fix works would pass).
* Overhauling these FixGenerators to use maps like the others is maybe
a good change in the long run, but at this point might be
over-engineering; we only have fixes for 2-3 codes for each file
type.
Change-Id: Iaa902acf2401f97ff722e222910f5d6fcd00a5ce
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/338800
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Auto-Submit: Samuel Rawlins <srawlins@google.com>
Originally we didn't use the LSP Request/Response classes, and just exposed the handlers through the legacy request/response.
However there were some mismatches (such as legacy protocol always returns Map<String, Object?> but some LSP requests return Lists, LSP using int|String IDs, and LSP having numeric error codes that don't match legacy string error codes).
This change uses LSP's request and Response by wrapping them inside a standard (legacy) handler. The LSP-over-Legacy handler has become a standard handler, and the params contain an "lspMessage" field that holds an LSP message, and the result contains an "lspResponse" field that contains an LSP response.
If an LSP handler returns an error, it will be returned as an error inside the LSP response, which will be in a _successful_ legacy request (since that's how we can return an LSP response - as the result).
Change-Id: I67973590ab32f3543d1a6e1b7279974e5e8832bc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/315201
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
No functional changes here but there have been some refactors inside the meta model that required some minor tweaks (URI moved from a type alias to string to a spec-defined base type).
I also improved the handling of some type references in the comments we bring in so they're clickable in more places.
Change-Id: I7c725d01b6d7bc0925979b8118dbfd8952f78724
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/297482
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Maybe? With an explicit type check we don't try to make an impression
that anything more happens here, e.g. for type parameters.
Similarly, for https://github.com/dart-lang/sdk/issues/36697 we would need to introduce `InvalidType`, which is not `DynamicType`. And so, `DartType.isDynamic` should not return `true` for `InvalidType`, it is not a property that various types may have, and should be replaced with explicit `is DynamicType`.
We also have `UnknownInferredType`, but it should never leak to clients.
Change-Id: I302b06355143d97bb52922c805dbad585a522e0a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/288340
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
With the parser code in the same library as the DOM classes, the
`pkg/analyzer/tool/messages/generate.dart` program, which generates all
of the diagnostic classes and diagnostics, _depends_ on a library
with a `parse` method which depends on these diagnostic classes (in
order to report errors while parsing HTML). This means that if
there is any existing error (like an unknown identifier) in the
existing error codes, it is impossible to generate the error codes.
Since we don't need the `parse` method to generate diagnostics, we
split up the library and remove the indirect dependency.
Separating the parser code out removes the loop.
Change-Id: Ifb9e9fd979e341ae64a1ed49aaf3758d3dcf1dee
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/287220
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
* Add a type argument to raw `Future` types (typically `Future<void>`)
* Add type arguments to raw `Map` types (typically Map<String, Object?>`)
* Add a type argument to raw `Completer` constructor calls.
* Use collection-elements in more places.
* Replace an implementation of `String.padLeft` and `String.padRight` with
StringBuffer extension methods that use `String.padLeft` and
`String.padRight`.
* Rename many `sb` variables to `buffer`, which is more idiomatic.
* Move some StringBuffer helper methods to be extensions on StringBuffer.
* Use constructor tear-offs instead of closures which call a constructor.
* Use single quotes where we can.
* Do not prefix constant names with the letter 'k' [1].
* In IntegrationTestMixin:
* Rename to `IntegrationTest`, as it is never used as a mixin.
* Public Stream fields are converted to be getters.
* Private StreamController fields are initialized at their declaration [2],
instead of an initialization method.
* Remove empty zero-parameter constructors.
[1] https://dart.dev/guides/language/effective-dart/style#dont-use-prefix-letters
[2] https://dart.dev/guides/language/effective-dart/usage#do-initialize-fields-at-their-declaration-when-possible
Change-Id: I7a923a80d32f74fbecf42a0fa35ae25285994097
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/281874
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
When getting completions, some of the "contributers" basically do a
walk of the AST and almost add everything they see, and the list
is then later pruned based on the user query.
This CL introduces a "first pruning" (a copy of the first part of what
is done in the subsequent pruning) so only the things has could match
the user query is added.
Benchmarks for this:
Notes:
- All of these numbers are with the timeout increased a lot (to a
point where there effectivley isn't any timeout).
- I have an external project too, but only in Android Studio as it's
a Flutter project and my VSCode then uses the dart included in
flutter. I don't know how to make it not do that.
Summary:
Android Studio, bin/server.dart --- `print(CallHierarchyK^);`
Difference at 95.0% confidence
-46.45 +/- 10.0349
-45.7861% +/- 9.8915%
(Student's t, pooled s = 15.6785)
Android Studio, bin/server.dart --- `starter.^;`
No difference proven at 95.0% confidence
Android Studio, Other project --- `print(Cryptm^);`
Difference at 95.0% confidence
-90.3 +/- 10.9506
-58.0894% +/- 7.04448%
(Student's t, pooled s = 17.1092)
VSCode, bin/server.dart --- `print(CallHierarchyK^);`
Difference at 95.0% confidence
-61.45 +/- 5.41501
-51.4226% +/- 4.53139%
(Student's t, pooled s = 8.46036)
VSCode, bin/server.dart --- `starter.^;`
Difference at 95.0% confidence
6.4 +/- 5.08317
15.4217% +/- 12.2486%
(Student's t, pooled s = 7.94189)
So for several queries it's ~50% faster. For a single one it slightly slower.
Raw numbers:
BEFORE:
Android Studio, bin/server.dart --- `print(CallHierarchyK^);`
90 ms
88 ms
89 ms
85 ms
139 ms
92 ms
86 ms
101 ms
87 ms
84 ms
112 ms
110 ms
128 ms
99 ms
99 ms
104 ms
98 ms
88 ms
106 ms
144 ms
Android Studio, bin/server.dart --- `starter.^;`
38 ms
38 ms
34 ms
30 ms
35 ms
34 ms
29 ms
31 ms
35 ms
60 ms
53 ms
37 ms
54 ms
31 ms
51 ms
33 ms
39 ms
68 ms
75 ms
91 ms
Android Studio, Other project --- `print(Cryptm^);`
150 ms
146 ms
142 ms
138 ms
150 ms
213 ms
147 ms
143 ms
149 ms
147 ms
153 ms
147 ms
136 ms
151 ms
151 ms
186 ms
160 ms
153 ms
150 ms
197 ms
VSCode, bin/server.dart --- `print(CallHierarchyK^);`
122 ms
113 ms
115 ms
118 ms
124 ms
116 ms
116 ms
114 ms
118 ms
125 ms
130 ms
117 ms
104 ms
119 ms
121 ms
120 ms
127 ms
123 ms
117 ms
131 ms
VSCode, bin/server.dart --- `starter.^;`
38 ms
45 ms
35 ms
37 ms
37 ms
59 ms
39 ms
38 ms
37 ms
44 ms
41 ms
41 ms
43 ms
41 ms
39 ms
40 ms
42 ms
43 ms
49 ms
42 ms
WITH CL:
Android Studio, bin/server.dart --- `print(CallHierarchyK^);`
65 ms
59 ms
41 ms
41 ms
70 ms
38 ms
56 ms
66 ms
64 ms
44 ms
47 ms
56 ms
46 ms
38 ms
46 ms
64 ms
57 ms
44 ms
69 ms
89 ms
Android Studio, bin/server.dart --- `starter.^;`
36 ms
36 ms
38 ms
35 ms
37 ms
43 ms
32 ms
30 ms
34 ms
39 ms
32 ms
40 ms
35 ms
34 ms
35 ms
39 ms
46 ms
54 ms
56 ms
78 ms
Android Studio, Other project --- `print(Cryptm^);`
59 ms
63 ms
61 ms
80 ms
98 ms
56 ms
60 ms
61 ms
57 ms
61 ms
57 ms
61 ms
59 ms
59 ms
57 ms
64 ms
60 ms
65 ms
58 ms
107 ms
VSCode, bin/server.dart --- `print(CallHierarchyK^);`
55 ms
54 ms
50 ms
47 ms
59 ms
55 ms
53 ms
53 ms
67 ms
67 ms
54 ms
54 ms
50 ms
62 ms
54 ms
54 ms
56 ms
59 ms
63 ms
95 ms
VSCode, bin/server.dart --- `starter.^;`
57 ms
41 ms
57 ms
40 ms
45 ms
47 ms
40 ms
44 ms
43 ms
43 ms
41 ms
40 ms
42 ms
49 ms
40 ms
46 ms
57 ms
49 ms
81 ms
56 ms
https://github.com/flutter/flutter-intellij/issues/6470
Change-Id: I1e34ce04774cafcb47f4e8590b990400a7b0f0ad
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/279389
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Sam Rawlins