No functional changes here, I'm just trying to simplify the hover implementation a little as this method had gotten quite long and deeply nested. We've discussed improving hover support for patterns and keywords and hopefully this'll make that easier.
Change-Id: I974f7fb0fbb99a967b5970f99b36ef3601df4ea3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/318701
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
No functional changes, just simplifies the tests a little by calling functions to set capabilities instead of having to nest them inside `initialize()` calls.
Change-Id: I1496da221b1802c3375c32c7e0d048310769bdf9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/317961
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Otherwise they'll be recorded as "lsp.handle".
Change-Id: I511d5eef44d6d647fef4d0347a03f6a7a9f88f9e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/315920
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Change-Id: I697bda0006cca5785694156d7cd84efcd008b545
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/318340
Reviewed-by: William Hesse <whesse@google.com>
Commit-Queue: Alexander Thomas <athom@google.com>
The test generates many classes, compiles a lot of code and executs very
large function.
This is too slow under TSAN
TEST=Skip vm/cc/ManyClasses on TSAN
Change-Id: I867fe9c1d50e7e976cd0a58659464c3eada5e56c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/318640
Reviewed-by: Tess Strickland <sstrickl@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
This is just a little refactoring towards https://github.com/Dart-Code/Dart-Code/issues/2462. It doesn't change anything, it just makes the next CL (with the functional changes) simpler.
Change-Id: I98ed5991f1abb67f86f9d4d43c27ff6ccf21847c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/317940
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@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>
I was trying out DCM and it found this bogus condition.
The only instance I can find where it triggered was adjacent interpolations in strings, and the fallback code (which compares by token type) would handle it correctly, but in case there are other cases (now or in future), I've added an assert to try to avoid reaching the fallback in case it doesn't produce the desired result.
Change-Id: I3092fa4892c812be7d3a91629c5f6ed3be627743
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/315720
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Several changes are made:
- createDartExport now does not export methods that define type parameters.
- createStaticInteropMock adds conformance checks to make sure implementing
members can handle all possible values of a type parameter in an interop
member. An error is added to reduce confusion around this.
- Export creator now uses dart:js_interop_unsafe for a lot of its lowering
as the dart:js_util equivalents are buggy when it comes to calling exported
functions in JS with JS types.
- Small code changes are added to backends to handle the above changes.
Change-Id: Ie3b6b157930537267f270b60373b2b17e0a14344
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/316141
Reviewed-by: Joshua Litt <joshualitt@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
If a condition is valid, but fails in an assert, make sure we report
that and a pseudo trace with context messages for the user to link
back to the problem.
This CL also starts building the stack trace when we call a super constructor for more detailed errors.
Bug: https://github.com/dart-lang/sdk/issues/36526
Change-Id: Ib9bc9841256644d2380d3f806e3bc3c9d84b37cf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/316625
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
After simplifying the handling of annotations in the kernel loader in
[0] we no longer need to use handle-based access to pragmas.
Also use bit field to represent detected pragmas.
[0] https://dart-review.googlesource.com/c/sdk/+/290502
TEST=ci
Change-Id: I2e21c9e96accce1580964e617f05e4316563b463
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/318260
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
When evaluating an expressino at a breakpoint that's inside a closure,
the closure may refer to anything it closes over. That includes the
`this` from an enclosing method.
So depending on whether a closure's parent chain is an instance method
or a static method, the expression evaluation function is going to be an
instance method or a static method.
=> We walk up the parent chain to determine the correct enclosing class.
=> This avoids making a Type object with a cid from a top-level class (see [0])
Handling this correctly will now try to get the `this` when invoking an
eval function that has an enclosing instance method. Though we may often
have "<optimized out>" the `this` (e.g. due to not capturing it in
closure context chain).
=> We still allow running the expression evaluation function in this
case, but only if the expression being evaluated doesn't access `this`.
A similar issue occurs when trying to use variables in the eval
expression that the closure didn't capture. This results in a confusing
CFE compile-time error. This is a separate issue and tracked in [1].
=> We update the test to distinuish the cases that this CL makes passing
and those that are failing due to [1].
Fixes [0] https://github.com/dart-lang/sdk/issues/53061
See also [1] https://github.com/dart-lang/sdk/issues/53087
TEST=Fixes part of service/evaluate_activation_test failures
Change-Id: I3bb24e7338c7b2f12d5340311d944cb59a455641
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/317540
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
