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>
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>
This is necessary to separate `ClassElement`, `EnumElement`, and `MixinElement`. And, in the future, augmentations like `ClassAugmentationElement`, etc.
Change-Id: Iecd2f8707212e53ef56f0e101880c7bab9e5d057
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/254104
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
For `InterfaceType` keep `element2` deprecated and define
`InterfaceElement get element2` instead. Most changes are because
of this.
Change-Id: I13b888610fc707438c3c97b676f1460e7fc2b040
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/253564
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
This involves changes of a few flavors:
* Make classes private which were unnecessarily public.
* Make class elements private which were unnecessarily public.
* Comment in places where a "public" API contains a private type,
but this is because of the signature of a super-member. I think
these are generally quite safe.
Change-Id: Ied1864202cc256205a3b421ddec5513f0a22a608
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/243647
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This involves a large refactoring of completion_metrics.dart, extracting
out some common code into completion_metrics_base.dart
The code in completion_metrics.dart and completion_metrics_base.dart is
largely unchanged, but restructured to fit the sub-class structure.
* Rename CompletionMetricsComputer -> CompletionQualityMetricsComputer,
as this is focused on quality metrics.
* Extract out applyOverlay and removeOverlay methods.
* Extract out computeSuggestionsAndMetrics, code which is run per
ExpectedCompletion.
* Extract out setupForResolution, for code custom to the quality
computer.
The meat of this change though is in completion_metrics_client.dart:
* _AnalysisServerClient is code which was extracted from
package:dartdev/src/analysis_server.dart. It may seem like an odd
choice when we have package:analysis_server_client, but I think
dartdev's client is fairly mature in creating a short-lived client,
and handling crashes, etc. If this should be re-combined with dartdev,
I think there are open questions about where that should live, and I'd
like to address that in a follow-up.
* The client does not perform overlays yet.
* The client does not track slowest requests yet.
* The client does not have support for performance metrics which DAS
tracks itself. Adding this is high priority.
Change-Id: Ib259f78e4646d10b61559bfd5700d98a95d14d43
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/243522
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This option allows the completion position to be an offset from the
start of each token, and plays well in each overlay mode. For the
original content:
```dart
void main() {
foo();
}
```
In OVERLAY_NONE mode, completing on `main`, with `--prefix-length=2`,
we complete at:
```dart
void main() {
^
foo();
}
```
In OVERLAY_REMOVE_TOKEN mode, completing on `main`, with
`--prefix-length=2`, we complete at:
```dart
void ma() {
^
foo();
}
In OVERLAY_REMOVE_REST_OF_FILE mode, completing on `main`, with
`--prefix-length=2`, we complete at:
```dart
void ma
^
```
Change-Id: Id2493777cb38f147f7a2c401a9e53e17561516bc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/241982
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Previously, the 'slowest requests' flag would only track and print the
slowest 5 requests for each category. But this ends up printing many
requests which are not slow at all, and are perfectly reasonable. It is
more interesting to print the slowest results, those in the 90th
percentile.
The limit is set to 100. This is to set a limit on serialization in the
map/reduce system, and a limit on printing to stdout.
Change-Id: I31fde906e227ea195ec25d8c9c2d92569ceb72b7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/241865
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Konstantin Shcheglov