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>
It's not necessary to call `FlowAnalysis.declare` from
`TypeAnalyzer.analyzeDeclaredVariablePattern` because the call that
immediately follows, `FlowAnalysis.assignMatchedPatternVariable`,
completely overwrites the variable's flow model.
Change-Id: I8293672c7fefec7eddfb4d43c38d81d8dcbe9aea
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/280202
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
There are two ways type promotion can occur when switch cases share a body:
(1) the scrutinee variable (if any) might be promoted, e.g.:
f(Object x) {
switch (x) {
case int _ && < 0:
case int _ && > 10:
// `x` is promoted to `int` because both cases promote the
// scrutinee variable to `int`.
}
}
(2) explicitly matched variables might be promoted at the time of the
match, e.g.:
f<T>(T t) {
if (t is int) {
switch (t) {
case var x && < 0:
case var x && > 10:
// `x` has type `T` but is promoted to `T&int`, because
// both declarations of `x` are in a context where the
// matched value has type `T&int`.
}
}
}
The existing flow analysis logic handles case (1) without any extra
work, because those promotions are joined as a natural consequence of
the flow control join at the end of matching the cases.
However, flow analysis has to do some extra work for case (2), because
the two copies of variable `x` are associated with different variable
declarations (and hence have different promotion keys). To ensure
that the promotions are joined in this case, we need to copy the flow
model for the two copies of `x` into a common promotion key prior to
doing the flow control join.
The bookkeeping necessary to figure out a common promotion key is
similar to the bookkeeping for logical-or patterns.
Bug: https://github.com/dart-lang/sdk/issues/50419
Change-Id: I9ee4ec5d797dae28099aafbaf34fbbeeee5cd626
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/280201
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
There are three ways type promotion can occur in an or-pattern:
(1) the scrutinee variable (if any) might be promoted, e.g.:
f(Object x) {
if (x case int _ && < 0 || int _ && > 10) {
// `x` is promoted to `int` because both sides of the `||`
// promote the scrutinee variable to `int`.
}
}
(2) the implicit temporary variable that holds the matched value might
be promoted, e.g.:
f(Object Function() g) {
if (g() case (int _ && < 0 || int _ && > 10) && (var x)) {
// `x` has type `int` because both sides of the `||` promote
// the matched value to `int`.
}
}
For this sort of promotion to work, we need to
(3) explicitly matched variables might be promoted at the time of the
match, e.g.:
f<T>(T t) {
if (t is int) {
if (t case var x && < 0 || var x && > 10) {
// `x` has type `T` but is promoted to `T&int`, because both
// declarations of `x` are in a context where the matched
// value has type `T&int`.
}
}
}
The existing flow analysis logic handles cases (1) and (2) without any
extra work, because those promotions are joined as a natural
consequence of the flow control join at the end of matching the
logical-or pattern.
However, flow analysis has to do some extra work for case (3), because
the two copies of variable `x` are associated with different variable
declarations (and hence have different promotion keys). To ensure
that the promotions are joined in this case, we need to copy the flow
model for the two copies of `x` into a common promotion key prior to
doing the flow control join.
The bookkeeping necessary to figure out a common promotion key is
similar to the bookkeeping necessary to track the association between
the individual declared variable patterns and the joined pattern
variable (and this is bookkeeping that flow analysis is already
doing). So as part of this change I went ahead and removed the
`getJoinedVariableComponents` method (which was previously used by
flow analysis to query this association). This reduces the
constraints on the analyzer and CFE implementations by not requiring
them to do this bookkeeping themselves.
In the process I've made two additional small changes:
- I modified the logic for assigning types and finality to joined
variables so that if there is a finality conflict but no type
conflict, the common type is used; conversely, if there is a type
conflict but no finality conflict, the common finality is used.
This should help reduce follow-on errors.
- I added logic to ensure that if a variable is only declared on one
side or the other of a logical-or, flow analysis still considers
that variable to be definitely assigned. This should help reduce
follow-on errors.
Change-Id: I62f17adb6a51a583707c216ed48d941d1c621eea
Bug: https://github.com/dart-lang/sdk/issues/50419
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/279756
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This handles cases where the running app/VM was unable to provide a file:/// URI (such as google3) by calling the VM Service to translate the URIs before providing them to the client (which likely only understands file URIs).
Change-Id: Ib0b5d554a21e14e04fac6c05e489f5cc03b8301c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/280107
Reviewed-by: Helin Shiah <helinx@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
This move the test of the "native" syntax, support by the CFE, to
a separate test. The test (expecting the syntax to _not_ be supported)
fails on the CFE but that has nothing to with the records/patterns
features which the remaining tests in syntax_test.dart require.
Change-Id: Idef0d8b58b24488bcd4e3318eac9638152056b2d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/280111
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Some fields of `OSThread` are initialized by retrieving information by
calling OS functions. For example, `trace_id_` is initialized by calling
`OSThread::GetCurrentThreadTraceId()`. Similarly, this CL adds the
`OSThread::GetCurrentThreadName()` method and uses it to initialize
`name_`.
TEST=CI
Change-Id: Iee121d71e660be01ff684a298144fa7d59e3b61d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/278662
Commit-Queue: Derek Xu <derekx@google.com>
Reviewed-by: Ben Konyi <bkonyi@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>
If we statically know the types are unrelated, there is like
no chance for the cast to succeed at runtime. This is likely
a sign that automatic migration went wrong somewhere and human
intervention is needed. The cast just delays the problem to
runtime. Skip the cast and let it fail at compile time instead.
Change-Id: Ib557650b368c8f2839029e8a2e54c6bf9474035b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/280119
Commit-Queue: Ilya Yanok <yanok@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
When lowering patterns, front-end can add multiple distinct local
variables with the same name into the same local scope.
Previously, VM identified local variables in a local scope by name.
However, this no longer works with patterns.
With this change, local variables are now identified by pair (name,
kernel offset). Name is still taken into account as compiler can add
extra variables which do not correspond to kernel variables,
such as 'this'.
TEST=runtime/tests/vm/dart/regress_51091_test.dart
Fixes https://github.com/dart-lang/sdk/issues/51091
Issue https://github.com/dart-lang/sdk/issues/49755
Change-Id: I0263769cb31f3f8d9652f5d6534800510ac882fb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/279650
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
なつき