Includes a fix for the serialization of the representation name found
through the update of the ast-to-text.
TEST=existing
Change-Id: Id741d66d8f43b5dc1d5e79f967b9625579539404
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/318941
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
The main purpose of the low-level [PortMap] is to coordinate between
ports being opened & closed and concurrent message senders. That's the
only thing it should do.
Each isolate owns [ReceivePort]s. Only the isolate mutator can create
ports, delete them or change their "keeps-isolate-alive" state. Right
now it requires going via [PortMap] (which acquires lock) and
[MessageHandler] (which acquires lock) to change the
"keeps-isolate-alive" state of a port.
We'll move information whether a dart [ReceivePort] is closed and
whether it keeps the isolate alive into the [ReceivePort] object itself.
=> Changing the "keeps-isolate-alive" state of the port no longer
requires any locks. We could even avoid the runtime call itself in a
future CL.
Isolates are kept alive if there's any open receive ports (that have not
been marked as "does not keep isolate alive"). This is a property of an
isolate not of the message handler. For native message handlers we do
have a 1<->1 correspondence between port and handler (i.e. there's no
"number of open ports" tracking needed).
=> We'll move the logic of counting open receive ports and ports that
keep the isolate alive to the [Isolate].
=> We'll also remove locking around incrementing/decrementing or
accessing the counts.
=> The [IsolateMessageHandler] will ask the [Isolate] whether there's
any open ports for determining whether to shut down.
=> For native ports, the `Dart_NewNativePort()` & `Dart_CloseNativePort()`
functions will manage the lifetime (as their name also suggests).
Overall this makes the [Isolate] responsible for creation of dart
[ReceivePort]s and tracking whether the isolate should be kept alive:
* Isolate::CreateReceivePort()
* Isolate::SetReceivePortKeepAliveState()
* Isolate::CloseReceivePort()
TEST=ci
Change-Id: I847ae357c26254d3810cc277962e05deca18a1de
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/317960
Reviewed-by: Alexander Aprelev <aam@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
If a thread owns a lock already before acquiring the safepoint
operation, it can re-acquire the same lock inside the safepoint
operation (as it's a NOP and canoot lead to deadlocks).
TEST=ci
Change-Id: I4a7c3526683e09d4408d97aca9e9b59d6ca53d19
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/318662
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
All uses of `PortMap::Create()` would call `PortMap::SetPortState()`
after creating the port. To avoid acquiring the port map lock twice, we
can initialize the state already in `PortMap::Create()`.
Additionally we fix an existing issue by making the isolate's main port
a control port (instead of leaving it as a `kNewPort`).
As a side-effect we'll no longer have any allocated ports with state
`kNewPort`.
We also remove the unused `PortMap::IsLocalPort()`
TEST=ci
Change-Id: I6198792a8e1132580b60262f10a807c5b12f9eaf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/317680
Reviewed-by: Alexander Aprelev <aam@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
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>
