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>
There has been reports of slow analyzer queries that ~locked up VSCode,
and I was given a (reproducable) example by @yousefi.
Turns out that, at least what I could reproduce, wasn't the analyzer
being slow, but rather the analyzer never responding to a query in
certain timing-related situations.
In the concrete example a test-script checks out another copy of the
directory opened by VSCode _inside_ the same directory (say root folder
opened by VSCode was "foo" and now it gets "foo_copy" inside it), this
causes `_destroyAnalysisContext` to be called, effectivley stopping all
in-flight queries via the stopped `AnalysisDriver`s, meaning that a
response is never given.
I can also reproduce the same thing by for instance having
`pkg/analysis_server` open in VSCode and then checking out a many
months old revision (while firering queries).
This CL is a suggestion for how to fix it: When disposing of an
`AnalysisDriver` we finish all waiting `Completer`s with an error,
this means a response is given and that VSCode stops waiting.
Change-Id: Idc04bf1d1d3f86a6d12bb77f5805064c67965209
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/269300
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Konstantin Shcheglov