LSP currently has no capability for showMessageRequest and assumed all clients support it. They do not.
Until there's a capability (and clients have been updated to pass it), we should assume there is _not_ support for this. So that it can be used in VS Code, we accept a custom flag in experimental that indicates support for this (which the current VS Code extension is passing).
When there is an official capability we should treat either as an indication of this being supported, and then further into the future we can drop the custom flag.
See https://github.com/microsoft/language-server-protocol/issues/1635.
Change-Id: I7ca36555a5a10231f754faf6ae0ba199f791be35
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/280173
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
I wasn't comfortable with the previous approach of fixing one
contributor at a time, so I tried handling a single location all at
once. I think it worked better, and might be easier to review.
So what that means is that I think the tests and changes cover
everything that needs to be done for object patterns. If you see
anything I missed, please let me know.
Change-Id: Ia4a5e8ed1cb7c1f68a96d5856165b239126ddfd4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/280124
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@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 adds the initial implementation of exhaustiveness checking in
the analyzer and CFE. The checking is currently only performed in
switch statements and only handle a subset of the patterns.
Change-Id: Ia0050c2c80fbefe3e22615599136f9d919ebe4ef
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/279173
Reviewed-by: Jonas Termansen <sortie@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
This CL adds a page "Collect Report" on the
"Analysis Server Diagnostics" website, available from the top right,
between "Diagnostics" and "Feedback".
The created json report includes most data from the subpages of the
"Diagnostics" page as well as data fetched from the observatory
protocol which, if not already enabled, will be enabled while the report
is created.
Change-Id: Iec545fb8caf642088c47ccfc98f005598a462ada
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/279093
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
This CL keeps slow (500+ ms) requests around for longer (to a total of
1000 of them), saves the start time of the request and prints a little
more on the details page.
The overall idea is that having a record of slow requests is better
for debugging performance related issues than only having the newest
50 requests which basically requires one to "catch it" as it's being
slow.
Currently the 500 ms deadline for "slow" and 1000 requests saved was
just grabbed from thin air; we can adjust them later if needed.
Change-Id: Ib0d6e1fc2daad215d8745249abdc82f831a83785
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/279087
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
* ARGUMENT_TYPE_NOT_ASSIGNABLE_TO_ERROR_HANDLER
* BODY_MIGHT_COMPLETE_NORMALLY_CATCH_ERROR
* BODY_MIGHT_COMPLETE_NORMALLY_NULLABLE
* DEPRECATED_EXTENDS_FUNCTION
* DEPRECATED_IMPLEMENTS_FUNCTION
* DEPRECATED_MIXIN_FUNCTION
* DEPRECATED_NEW_IN_COMMENT_REFERENCE
This requires allowing these warnings to be reported in language tests without being expected.
Also, observatory now must comply with BODY_MIGHT_COMPLETE_NORMALLY_NULLABLE (or we could ignore the diagnostic).
TESTED=unit tests
Change-Id: I8facfa48a8645bac5bf8037163076a8f0a0ad05e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/275740
Reviewed-by: Ben Konyi <bkonyi@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Danny Tuppeny