This fixes a bug where we'd produce the wrong absolute path for stack frames that had absolute paths (because `package:stack_trace` uses `path.absolute()` on them).
It also adds support for making stack frames in printed stack traces faded if they are not part of the users own code. This is something the legacy DAPs did. I've also made it possible to perform this stack parsing on non-error events because I'd like to use it on Flutter structured errors (again, something we supported in legacy adapters and was missing here).
Fixes https://github.com/Dart-Code/Dart-Code/issues/4573,
Change-Id: I6c1c3ab69915eca9a1eeef5dcba7f1eb558086de
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/311842
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
This currently only allows "textDocument/hover". Handlers may need some tweaks to remove any dependencies on LspAnalysisServer before they can be enabled.
Capabilities and config are hard-coded to a very basic set (which I suspect will expand as new handlers are added). Reverse requests and notifications are not currently supported (I suspect these will be added when there are more concrete use cases for them because they may need to be conditional based on real client capabilities/needs).
Change-Id: I8a096f9530ad1518ac5ee876aea2560d269a27ae
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/312303
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
The goal here is to ensure tests can't accidentally check only a subset of edits made during the command execution.
Not all tests have been migrated (only refactorings and a few that happened to use some of the same methods for verification).
Change-Id: I5589e8e667e957aee3ea55f741b1b49a3859d6bd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/312304
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
The issue here was that isInMask does not hold inversely. The key is that we want to verify which refinements to skip, therefore we want to calculate *in*valid refinements. We want to skip refines where the new type is a Union AND the old tpye is a supertype of the new type. after.isInMask(before) gives us that but !before.isInMask(after) does not.
I've renamed isValidRefinement to isInvalidRefinement to more accurately capture this distinction.
Change-Id: I0d99479357a140095a5d0dfb7e2f987556097891
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/312160
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
Add ClassAugmentationElementImpl, no any tests yet because it
required parsing, AST, etc. And it is also not ready yet.
Change-Id: I601141545e9bf0638771f28bb9498be9de664659
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/312345
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
These are intended to be applied by annotating a library directive.
Note that some parameter types had to be widened since `Library` is not a subtype of `Declaration`. Ultimately I think that is fine though.
Bug:https://github.com/dart-lang/language/issues/2839
Change-Id: Ia1311c8aea729f2bd8b76173ce4c7595a6a37a42
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/312140
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Auto-Submit: Jake Macdonald <jakemac@google.com>
Commit-Queue: Jake Macdonald <jakemac@google.com>
I started initially with the idea to move 'mixinInferenceCallback'
to `ClassElementImpl`, but then realized that we do it for enums too.
So, it should stay in `InterfaceElementImpl`.
I left with code that I think slightly modernized, so decided to
send it for review.
Change-Id: Ib990392dc4985a71ffba1f4080237872d9a65ad2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/312521
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Previously, the FFI transformer could produce is checks where the
type to check against was Pointer<dynamic>. However, given that
the Pointer class is defined as:
abstract class Pointer<X extends NativeType> ...
the instantiated to bounds version of its type is Pointer<NativeType>.
Pointer<dynamic> is not a subtype of Pointer<NativeType>, and thus is an
invalid instantiation, but the only place this type could occur was as
the right hand side of an is check.
Before 7cc005ea1, Class::RareType() returned the class instantiated with
the null (all-dynamic) type arguments vector. Among other things, this
"rare" type was compared to the right-hand side of is checks and, if it
matched, performed a simple (cid-only) check of the instance type
arguments in unoptimized code.
Afterwards, Class::RareType() returns the class instantiated with a type
arguments vector where each type parameter is instantiated to bounds, so
now the "rare" type check fails and it falls back to the full check of
the instance type arguments, which causes a ~25% regression in some
unoptimized benchmarks.
This CL fixes the generation of those is checks in the FFI transformer
to use the instantiated to bounds version of the Pointer type instead.
TEST=pkg/front_end/test
Issue: https://github.com/dart-lang/sdk/issues/52843
Issue: https://github.com/dart-lang/sdk/issues/52848
Cq-Include-Trybots: luci.dart.try:vm-ffi-qemu-linux-release-riscv64-try,vm-ffi-qemu-linux-release-arm-try,vm-aot-linux-debug-x64-try,vm-linux-debug-x64-try
Change-Id: Ic9ac6d75ba2743e233065444fad13ab098094349
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/312400
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
Auto-Submit: Tess Strickland <sstrickl@google.com>
Commit-Queue: Tess Strickland <sstrickl@google.com>
It's still unclear why this is causing an issue but this will unblock b/285636639 until the underlying cause is found and fixed.
Change-Id: I44db6059a13738d5781c0557810ee53556ecb9c0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/312100
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
The main contribution of this CL is unification of disparate
handling of various functions like `Future.timeout`,
`Future.wait`, `_SuspendState.createAsyncCallbacks` and
`_SuspendState._createAsyncStarCallback` into a single
`@pragma('vm:awaiter-link')` which allows Dart developers
to specify where awaiter unwinder should look for the next
awaiter.
For example this allows unwinding to succeed for the code like this:
Future<int> outer(Future<int> inner) {
@pragma('vm:awaiter-link')
final completer = Completer<int>();
inner.then((v) => completer.complete(v));
return completer.future;
}
This refactoring also ensures that we preserve information
(including Function & Code objects) required for awaiter
unwinding across all modes (JIT, AOT and AOT with DWARF stack
traces). This guarantees users will get the same information
no matter which mode they are running in. Previously
we have been disabling awaiter_stacks tests in some AOT
modes - which led to regressions in the quality of produced
stacks.
This CL also cleans up relationship between debugger and awaiter
stack returned by StackTrace.current - which makes stack trace
displayed by debugger (used for stepping out and determinining
whether exception is caught or not) and `StackTrace.current`
consistent.
Finally we make one user visible change to the stack trace:
awaiter stack will no always include intermediate listeners
created through `Future.then`. Previously we would sometimes
include these listeners at the tail of the stack trace,
which was inconsistent.
Ultimately this means that code like this:
Future<int> inner() async {
await null; // asynchronous gap
print(StackTrace.current); // (*)
return 0;
}
Future<int> outer() async {
int process(int v) {
return v + 1;
}
return await inner().then(process);
}
void main() async {
await outer();
}
Produces stack trace like this:
inner
<asynchronous suspension>
outer.process
<asynchronous suspension>
outer
<asynchronous suspension>
main
<asynchronous suspension>
And when stepping out of `inner` execution will stop at `outer.process`
first and the next step out will bring execution to `outer` next.
Fixes https://github.com/dart-lang/sdk/issues/52797
Fixes https://github.com/dart-lang/sdk/issues/52203
Issue https://github.com/dart-lang/sdk/issues/47985
TEST=ci
Bug: b/279929839
CoreLibraryReviewExempt: CL just adds @pragma to facilitate unwinding
Cq-Include-Trybots: luci.dart.try:vm-aot-linux-product-x64-try,vm-aot-linux-debug-x64-try,vm-aot-linux-release-x64-try,vm-aot-obfuscate-linux-release-x64-try,vm-aot-dwarf-linux-product-x64-try
Change-Id: If377d5329d6a11c86effb9369dc603a7ae616fe7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/311680
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
Allows you to ask for the types in a library in the declarations phase, and all
the top level declarations in the definitions phase.
Bug: https://github.com/dart-lang/language/issues/2839
Change-Id: If0f8fb777fd8a006d686d457cf5d5ca11fcca9ee
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/311900
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Jake Macdonald <jakemac@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
In order to share LSP handlers between protocols, we need to be able to use a LegacyAnalysisServer in place of an LspAnalysisServer which means having a common interface (which they have via AnalysisServer) and to make the mapping of LSP method names to handlers reusable.
This changes makes the following non-functional changes (to reduce the size of a future change that will begin sharing handlers):
- Rename "clientCapabilities" to "lspClientCapabilities" to avoid conflicts with legacy servers clientCapabilities field when we add this to the base AnalysisServer interface
- Rename "clientConfiguration" to "lspClientConfiguration" for consistency
- Add an "LspMessageHandler" typedef over "MessageHandler" which now has a server type arg so that it can be used with either LspAnalysisServer (by handlers that really need LSP) and AnalysisServer (for handlers that can work in either server)
- Extract handler generators in `InitializedStateMessageHandler` to a static map and make constructors consistent taking only a server (in a future CL the legacy server will want access to some this mapping)
Change-Id: I23554a7ca318fbcd1113dcebff5601186b223618
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/311982
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Checking the offset can be wrong on Windows due to line endings. Other tests in this file are checking the message, so I've done the same here.
I noticed this locally, but I see the Windows bot was also failing on this.
Change-Id: I36de86c3b3eac6f379da894ea9e6fcfcb1a0aa4a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/311981
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This adds FileUriConstantExpression, a subclass of ConstantExpression, to support correct file offset of annotations for augmentations and patches.
The FileUriExpression is used to carry the file uri of the expression
before constant evaluation.
TEST=general/patch_annotations
Change-Id: I0dc8a0cb97dd530fd1960785d38c2d5e4883c3dd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/311660
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
More details about the design:
https://docs.google.com/document/d/1QDjyY_6wOTOgURwpeYMKU9qEz0gKxx2MUrdruC6Kp6c/edit?usp=sharing
Change-Id: Ie3985d86dca7f5010044ca46c33ca177588c0f69
Bug: #37022
CoreLibraryReviewExempt: Reviewed by vm and api groups. web and wasm groups not affected because FFI isn't on those platforms.
TEST=async_void_function_callbacks_test.dart, ffi_callback_metadata_test.cc, other front end tests
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/305900
Commit-Queue: Liam Appelbe <liama@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
E.g. if asking the tool to figure out any performance changes to
revision 5222bfd90c it will checkout 5222bfd90c and 2037563b94
(the previous commit), make aot-snapshots for both and run both on
the same (specified) target.
Change-Id: Ief56843326343ebaa681df596162d1d08457a8f7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/311602
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
When there are multiple isolates, we may get breakpoint responses/events like this:
- Request/Response to add breakpoint to Isolate 1
- Request/Response to add breakpoint to Isolate 2
- BreakpointAdded for Isolate 1
- BreakpointResolved for Isolate 1
- BreakpointAdded for Isolate 2
Because Isolate 2 did not load the script, the last breakpoint was never resolved. However because the breakpoint ID matched, we would forward this event to the client and un-resolve the previously resolved breakpoint. This would result in odd behaviour in VS Code.
Additionally, the VM may return the same BM breakpoint ID for what the client thinks are two breakpoints (they are on different lines, but resolve to the same location) so when we get a resolved breakpoint, we need to handle both:
- Client breakpoints that have already been transmitted
- Future client breakpoints that may resolve to this same VM breakpoint
The previous code assumed that a BreakpointResolved event could be handled just once. Either for an existing breakpoint, or a future one.
This change swaps from storing queued events to storing the resolution information for each breakpoint, and it does this even if there was an existing breakpoint (in case the breakpoint is reused in future).
Fixes at least some of https://github.com/Dart-Code/Dart-Code/issues/4598
Change-Id: I53b92debfaa0c8f538dc8d67966854bb89634708
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/311480
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
The main difference from the previous harness is that it
allows auto updating the expectations instead of
maintaining them manually.
This relands 0c1b2722ed with
changes to harness which fix issues on Windows.
Note: some amount of AOT failures are expected and should just
be approved. They will be fixed with the last CL in the series.
TEST=ci
Cq-Include-Trybots: luci.dart.try:vm-win-release-x64-try
Change-Id: I7ae84769ed54bc447ebf71acc68ba9d0b6717bac
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/311604
Reviewed-by: Tess Strickland <sstrickl@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
Auto-Submit: Slava Egorov <vegorov@google.com>
Commit-Queue: Tess Strickland <sstrickl@google.com>
This reverts commit 0c1b2722ed.
Reason for revert: Failures on AOT (stack expectations unmet) and Windows (parse errors due to Windows paths) trybots.
Original change's description:
> [vm] Rename tests causal_stacks -> awaiter_stacks and improve harness.
>
> The main difference from the previous harness is that it
> allows auto updating the expectations instead of
> maintaining them manually.
>
> TEST=ci
>
> Change-Id: I80e303d3ecbcc834ac94fa089cabe4f8834cc661
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/311400
> Reviewed-by: Alexander Markov <alexmarkov@google.com>
> Commit-Queue: Slava Egorov <vegorov@google.com>
Change-Id: I7311bf08403f4167f88f6204fde1a6fdee353f7d
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/311600
Commit-Queue: Slava Egorov <vegorov@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
The main difference from the previous harness is that it
allows auto updating the expectations instead of
maintaining them manually.
TEST=ci
Change-Id: I80e303d3ecbcc834ac94fa089cabe4f8834cc661
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/311400
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
The name is more accurately reflects what this stack trace
contains: despite what causal implies it does *not* actually
reflect the stack which initiated the async operation. Instead
it contains the chain of listeners which will run when
the async operation completes - its awaiters.
TEST=ci
Change-Id: Ie7309c9b1c39246e0fd4c14f7b9c515bcdfbbe10
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/311384
Reviewed-by: Derek Xu <derekx@google.com>
We no longer rewrite suspendable function into closures nested
inside the original function, so the whole synthetic async breakpoint
machinery is not needed.
Refactor `Breakpoint` class to make one-shot and per-closure
separate properties of breakpoint, which allows creating
one-shot-per-closure breakpoints.
TEST=existing service tests
Change-Id: I208afe13f36efa40f5746e44867bd24684cf5f03
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/310601
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Reviewed-by: Derek Xu <derekx@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
This is done through a synchronized cache between the server and client. When serializing a remote instance, if the server has already serialized that object then it will only send the ID in the future.
These caches currently only live as long as a single macro application in a given phase, but could live longer in the future. They do need to get reliably cleared out to avoid memory leaks though, and the shorter lifetime is easier to manage consistently.
This also allowed me to remove the specialized server/client modes (clients would always only send back IDs previously).
Change-Id: I4e8a102403153829d66b0ac379636f5a95a70cea
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/311420
Commit-Queue: Jake Macdonald <jakemac@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
- Only include the script tag src if it differs from the previous log entry.
- Use single letters for each event field's key.
- Fix some typos.
- Remove 'uri' from download event as it can be inferred from script tag src and part file name.
Change-Id: Ib7916ea5e92720a10c7e1e1cab2e535fae2bbf49
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/311180
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
Will be used on dart.dev for customizing the highlight syntax in code blocks to be red underlines rather than yellow highlighting.
Related: https://github.com/dart-lang/site-www/pull/5006
Change-Id: Ib33ee8f6f7307efb649b627dfd9a5d90187cca1a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/311500
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
On a large app (which apparently has too many unused dependencies),
size of the AOT kernel file:
before: 464 MB
after: 108 MB
TEST=pkg/vm/testcases/transformations/type_flow/transformer/libraries.dart
Bug: b/287638965
Change-Id: I79a26305c00741babb6a69a18919983b398109e5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/310772
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
If we use just the session that produced the resolved unit, we will
not update other packages for example.
I tried to apply a refactoring to `LanguageVersionImpl` from `_fe_analyzer_shared`, and it did not update `analyzer`. With this change it does update :-)
Change-Id: I47fc28b4adba59c8e025e1bfe17490e4038d28ba
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/310973
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
To refuse confusion between dart:ffi and dart:js_interop,
top-level externals will need to be annotated when using
dart:js_interop.
Change-Id: I1e4887eb32f135df94426e43fc885346f1b9f1b1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/310485
Reviewed-by: Joshua Litt <joshualitt@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
- Make CorrectionProducer as base class for {Parsed/Resolved}CorrectionProducer.
- Use ParsedCorrectionProducer for ConvertDocumentationIntoLine
- Move sort imports test to used ParsedUnitResult
- Add getter to LintRule to indicate that rule can be run using just parsed AST
Change-Id: Id11466c445e6e505ea752d097b57143f18c47060
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/310484
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Keerti Parthasarathy <keertip@google.com>
The existing 'evaluateGettersInDebugViews' evaluates getters eagerly which can have side-effects. This adds a setting that allows showing getters in a way that can be shown lazily instead.
I added a new setting (instead of just making evaluateGettersInDebugViews=false be lazy) to preserve the ability to have getters not shown at all (since some users are using that today and might prefer this over lots of lazy getters showing up).
Fixes https://github.com/Dart-Code/Dart-Code/issues/4234
Change-Id: I56c2a7c8f85aa8c4cc85cfb3120a8cfec6b54c70
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/310164
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
When adding new breakpoints, DAP clients send a full new set of breakpoints which results in us removing and re-adding all breakpoints (for a file).
When we re-add a breakpoint that already existed, we would sometimes get the BreakpointAdded event _before_ the addBreakpointWithScriptUri request completed. We couldn't process the event because without the original request completing we could not map the VM breakpoint back to the clients breakpoint to generate the event.
This could result in resolution events being lost, and breakpoints becoming unresolved when you modified them (depending on timing).
This change collects queues and replays any BreakpointAdded/BreakpointResolved events that arrived when the breakpoint ID is unknown, and when `addBreakpointWithScriptUri` completes, it immediately processes any items in this queue.
Fixes https://github.com/Dart-Code/Dart-Code/issues/4599
Change-Id: I11daaf99b786ab94f1cc93f9fd38a4f1e241320f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/310620
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
This logic was inverted and could result in duplicate terminate requests being sent. Depending on timing, this request might be sent but not responded to (because the DA was already shutting down), causing a "Application terminated with pending terminate request" error.
Change-Id: If89f002792878f8a5ce12341536be70ee01cde11
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/310380
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
This is some prepration for starting the refactoring of the completion
support. The plan is for `InScopeCompletionPass` to implement the first
pass of the proposed algorithm. My intention is to convert one
contributor at a time (as much as possible), starting with the
`KeywordContributor`.
Change-Id: I206c704f5c2370f4c37b674be01ab7fb55afa65e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/310200
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
- Adds toDartInt and toDartDouble to JSNumber
- Changes semantics of int on external functions from truncate to
assert integer value
- Adds tests for number semantics
- Renames JSExportedDartObject -> JSBoxedDartObject to avoid confusion
with @JSExport
- Adds Object.toJSBox
JSNumber.toDart and Object.toJS will be removed in a future CL once
migrations are complete.
CoreLibraryReviewExempt: Backend-specific library.
Change-Id: I8ff26ee5624c52703e49dd8483f62e829cb6fff0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/309081
Reviewed-by: Joshua Litt <joshualitt@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
We believe that it is not necessary anymore, with sound null safety.
Change-Id: I18741eafea1bd969139cdae3b94a294dde1b5abd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/310769
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
On my Windows PC, this test often fails because the new content is never hot reloaded because the modification is made too soon after the app starts.
This change does what some Flutter tests do, which is to write a future modified stamp to ensure the file is considered updated when the reload is issued.
Change-Id: If52086fb279897d3e572162dc3a32436fbdb27c1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/310400
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
Add CONST_FOR_LOOP error message to be clearer that for loops are not
allowed in const contexts.
visitListLiteral handles Constants.
Change-Id: I84465ecf4e1f044c256db45c723fac081b50a40c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/306917
Commit-Queue: Kallen Tu <kallentu@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
I would like to use `Selection` for code completion, but the current
definition of `coveringNode` too often favors the parent node over the
child node. This will effectively cause the cursor to bind more closely
to an identifier token than to other tokens, making it more useful for
code completion.
If we don't like this change for the general case, I can make these changes in a specialized `coveringNodeForCompletion`, but I'd rather not have two approaches.
Change-Id: I39e70f83ad44d50cec55a8bee1f7061dd83746fe
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/310060
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Prior to this change, the first phase of flow analysis, in which flow
analysis "looks ahead" to see which variables are potentially assigned
in each code block, was failing to properly account for variables that
are assigned by pattern assignment expressions. This "look ahead"
information is used by flow analysis to determine the effects of
nonlinear control flow (e.g. to figure out which variables to demote
at the top of a loop, or to figure out which variables are potentially
assigned inside a closure). As a result, it was possible to construct
correct code that would be rejected by the analyzer and compiler, as
well as incorrect code that would (unsoundly) be accepted.
The fix is to call `AssignedVariables.write` from the analyzer's
`FlowAnalysisVisitor`, and from the CFE's `BodyBuilder`, to let flow
analysis know about variable assignments that occur inside pattern
assignment expressions.
Fixes#52745.
Change-Id: I0e6f426a5c5c36f214d5a206aaf5a2de0bfdaac1
Bug: https://github.com/dart-lang/sdk/issues/52745
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/310502
Auto-Submit: Paul Berry <paulberry@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Simple functions can be printed in dart_object_printer.dart.
Moving function reference tests around so they can be easily found together.
Change-Id: If022721f7dca4881d51cbebd65ed968cd89c33c0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/308261
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
This adds basic infrastructure for a stringref implementation in
dart2wasm:
- A `--[no-]stringref` option to the compiler
- An option in the `WasmTarget`, controlling the name of the target
- Separate sets of patch files for the two targets
- Separate platform dill files for the two targets
For now, the patch file contents are the same, and the compiler flag
is not used by the backend (only by the `dart2wasm` script to select
the appropriate platform dill file). Both of these will change as the
implementation progresses.
Tested: ci + manual check that the option selects the correct dill
Change-Id: I2c9bb95ba06fd3de3f7007703ef545e3f0c728ba
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/310621
Commit-Queue: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
The whole directory is already copied to the device. This makes
it consistent with tests running on the host and allows us to
access various artefacts (e.g. SO files containing DWARF
information).
Change-Id: I9fe20fdbb48ad5a3742286a84c87f87f580f2c09
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/310600
Reviewed-by: Tess Strickland <sstrickl@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
The following would fail unminified because the variable shadowed the
global JavaScript constructor. The fix is to add more global names to
the avoid-list. This is not a problem for js-interop since those are
accessed via `self` or `globalThis`.
```
import 'dart:typed_data';
foo(int Float32Array) => Float32List(Float32Array);
main() => print((foo)(10));
```
Change-Id: I887ece4a888fdab5df437822f9f1f34b384ec24f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/310482
Commit-Queue: Stephen Adams <sra@google.com>
Reviewed-by: Nate Biggs <natebiggs@google.com>
Constant Sets now have their own classes rather than being constructed as a wrapper over a const Map. The new scheme is similar to Maps - using a ConstantStringSet backed by a JavaScript Object 'dictionary' when the elements are all suitable String values, otherwise using a GeneralConstantSet backed by a list of elements that is converted to a lookup map on demand.
Constant Sets and Maps with suitable String keys are backed by a JavaScript Object literal 'dictionary'. The use of the Object literal has been changed so that the property values are no longer the values of the Dart Map, but the position of the key in the order of the entries. The values are provided as a List (Array), so there is an additional indexing operation to access the value on lookup. This does not seem to affect performance.
The advantage of the two-level lookup using the 'dictionary' is that Maps with the same keys (in the same order) can share a 'dictionary'. In order to achieve the advantage, the JavaScript Object is modeled as a first class ConstantValue - JavaScriptObjectConstantValue.
These changes achieve a code size benefit of -0.90% (~130K) on the main unit of a certain large app, and -0.35% for flute/benchmarks/lib/complex.dart
Change-Id: Icad2e6136218486a439e3c5ed0296462e3c3c4e6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/310020
Commit-Queue: Stephen Adams <sra@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
A lot of this change is just documentation comments, but it includes some minor updates such as supporting "lazy" on variables.
All changes are backwards compatible and this should not affect any tests or functionality of Dart's DAP implementation (but provides the ability for us to use the new features).
Change-Id: Ief81927f2f370b4bfb6b5a9acc8659c45c33ea18
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/310161
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
When an isolate is paused, we store some data for things like variables, stack frames, etc. to round-trip an identifier to the client that it can ask about later.
Previously we never cleared these, so over time in a long debug session they could build up. The DAP spec says these references become invalid when execution is resumed:
> To simplify the management of object references in debug adapters, their lifetime is limited to the current suspended state. Once execution resumes, object references become invalid and DAP clients must not use them.
Because it's possible to resume one thread without another, I'm clearing up only the specific thread (isolate)s data when it resumes, rather than all of it.
Fixes https://github.com/Dart-Code/Dart-Code/issues/4420
Change-Id: I2ba7d9cd3f23b5a628d9e279e49edf2bee5afd29
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/310342
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Any adb failures when test_runner runs tests on android devices,
except an failure of the actual precompiled test when it is run,
should be reported as an infra failure and should shut down the
test runner.
After change https://dart-review.googlesource.com/c/sdk/+/291304
these types of failure were reported as test failures instead.
Fixes: b/281492587
Change-Id: Iea47ccffac81b0b92f3a3fb3780d2181d08fc1d1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/310260
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: William Hesse <whesse@google.com>
This adds a check that all annotations of macro classes correspond
to applied macro applications. This should be improved in the future
to detect what the problem with the annotation was. For now it helps
avoid inadvertently using invalid/unrecognized annotations in the
macro feature development.
Change-Id: I9574e2e24150d2febfc5489ab4ebf0ae2627e3fd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/310101
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Initial commit at https://dart-review.googlesource.com/c/sdk/+/276100
used kb because that's what was reported by the system.
I wasn't allowed to add that to golem though, and then I forgot about
it.
This CL changes it to bytes so it can hopefully by allowed into golem.
Change-Id: Ia7fae9ed47e6d237648e266c26f4a644f13571d3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/310160
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Use JS `setTimeout` for events and `queueMicrotask` for micro-tasks.
dart2js event loop implementation is copied in `run_wasm.js` to be able
to use `clearTimeout`, `setInterval`, `clearInterval`, and
`scheduleMicrotask`, which are not not available in d8, and `setTimeout`
in d8 does not wait before calling a callback.
New passing d8 tests:
- co19/LibTest/async/Future/Future.delayed_A01_t02
- co19/LibTest/async/Stream/Stream.periodic_A01_t01
- co19/LibTest/async/Stream/Stream.periodic_all_t01
- co19/LibTest/async/Stream/Stream.periodic_all_t02
- co19/LibTest/async/Stream/timeout_A04_t01
- co19/LibTest/async/StreamController/stream_all_A01_t01
- co19/LibTest/async/StreamController/stream_all_A01_t02
- co19/LibTest/async/StreamController/stream_all_A02_t01
- co19/LibTest/async/StreamController/stream_all_A02_t02
- co19/LibTest/async/StreamController/StreamController.broadcast_Stream_all_A01_t01
- co19/LibTest/async/StreamController/StreamController.broadcast_Stream_all_A01_t02
- co19/LibTest/async/StreamController/StreamController.broadcast_Stream_all_A02_t01
- co19/LibTest/async/StreamController/StreamController.broadcast_Stream_all_A02_t02
- co19/LibTest/async/Timer/Timer.periodic_A01_t01
- co19/LibTest/async/Timer/Timer_A01_t01
- co19/LibTest/core/Stopwatch/elapsedTicks_A01_t01
- language/async/call_test
- language/regress/regress21795_test
- lib/async/multiple_timer_test
- lib/async/periodic_timer2_test
- lib/async/periodic_timer3_test
- lib/async/periodic_timer4_test
- lib/async/schedule_microtask3_test
- lib/async/schedule_microtask_test
- lib/async/stream_timeout_test
- lib/async/timer_isActive_test
- lib/async/timer_repeat_test
- lib/async/timer_test
New passing Chrome tests:
- co19/LibTest/async/Stream/timeout_A04_t01
- language/async/call_test
- lib/async/schedule_microtask3_test
Tests below fail because of async* desugaring issues and will be fixed
separately:
- language/async_star/no_cancel2_test
- language/async_star/no_cancel_test
Tests below fail because of an existing issue (#29615):
- co19/LibTest/async/StreamController/StreamController.broadcast_Stream_all_A01_t03
- co19/LibTest/async/StreamController/StreamController.broadcast_Stream_all_A02_t03
- co19/LibTest/async/StreamController/stream_all_A02_t03
Fixes#51599.
Change-Id: Ib313e99bf3b3cb3bebeddc9e47dc77425ef94481
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/305201
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Joshua Litt <joshualitt@google.com>
Commit-Queue: Ömer Ağacan <omersa@google.com>
Pointer.fromFunction returns a native function pointer to a Dart
function, but has the restriction that the native code must invoke it
on the same thread as the isolate that created it. RawVoidCallbacks is
a new API that is similar to Pointer.fromFunction. It returns a native
function pointer that can be invoked on any thread, with the
restriction that the Dart function must return void. Under the hood we
forward the function args over a port to the target isolate.
We're not 100% settled on the name of the class, but the overall API
design won't change. I'll make sure to get the naming finalized before
submitting this CL. Doc with discussion of naming:
https://docs.google.com/document/d/1z9Rgahoid2AhC9JXwsDAEODvlJS6dvBHCbcGkOxv_ws/edit?resourcekey=0-TbdNiSL-fdwskla02QaPwg#heading=h.te70ikwelbw8
Bug: https://github.com/dart-lang/sdk/issues/37022
Change-Id: Iba98f6f803c52919b942fa054df1060991574c8c
TEST=ffi_async_callback_test.dart
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/308860
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Liam Appelbe <liama@google.com>
Reviewed-by: Marya Belanger <mbelanger@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Danny gave a good idea that checking for availability of a refactoring
should be cheap. Change method signature refactoring mostly satisfied
this, with one exception - we cannot compute formal parameters for
an ExecutableElement, because we need resolved AST to do this, and
the invoked method can be declared in a different file. We cannot
afford resolving other files while checking.
So, this CL separates availability checking, and preparing formal
parameters, postponing expensive opertions until the time when the
action is invoked.
Change-Id: Ic703d70717e41de304c9dbcef66cadb22c139ad8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/310041
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This change updates the flow analysis support for field promotion
(which is not yet switched on by default) so that it supports field
accesses inside cascade expressions. The key moving parts are:
- The type hierarchy `PropertyTarget` (which is used by the client to
tell flow analysis whether the target of a property access is
`this`, `super`, or an ordinary expression) now has a new class,
`CascadePropertyTarget`, to represent the situation where the target
of the property access is an implicit reference to the target of the
innermost enclosing cascade expression.
- Flow analysis has two new methods on its API:
`cascadeExpression_afterTarget` and `cascadeExpression_end`, so that
the client can inform flow analysis when a cascade expression is
being analyzed.
- Flow analysis uses its `_makeTemporaryReference` method to track the
implicit temporary variable that stores the target of cascade
expressions. (This method was developed as part of flow analysis
support for patterns, where it creates the data structures necessary
to track the implicit variables that are created as part of pattern
desugaring).
- The "mini-AST" pseudo-language used by flow analysis unit tests now
has a way to represent cascade expressions and method invocations.
- In addition to unit tests for `_fe_analyzer_shared`, `analyzer`, and
`front_end`, there are new language tests in
`tests/language/inference_update_2` to test cascaded field
promotions in end-to-end fashion.
Bug: https://github.com/dart-lang/language/issues/2020
Change-Id: I21353bbc884ed599cb1739cecfb68ad1d975d18b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/309220
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Type rules for classes appearing in the type hierarchy above types
in the current module were missing. Specifically types that appear
in instantiations of supertypes.
Issue: https://github.com/dart-lang/sdk/issues/48585
Change-Id: I11f2af1435f18ab7567766c865d9898d60b9272b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/309827
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
When mixin applications introduce forwarding stubs with covariant
checks they can contain uses of type parameters that belong to the
synthetic mixin application class. The type environment needs to
be updated to contain those type parameters.
Also cleanup some comments, variable names, and the code to avoid
an assertion failure. Methods can contain covariant checks on the
arguments, not just setters.
Issue: https://github.com/dart-lang/sdk/issues/52688
Change-Id: Ifd91f76de85cb2092b0a3a0c4a808f2660eb5c17
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/308460
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
The type arguments have to be explicitly given for collection types,
but this should be doable given they are all constants and only certain
types are allowed.
Change-Id: I2721f37d194d73de1df81302298101adeb87534c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/309460
Commit-Queue: Jake Macdonald <jakemac@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
This adds assertions that no verification errors are found.
This enables the distinction between compile-time errors and
verification during trybot testing, leaving the latter as crashes
rather than (unexpected) compile-time errors, while retaining the
good diagnostics.
Change-Id: I097d875a75e8343c67cb96190b53320d4799663c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/309662
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
This ensures that abstract methods have sync markers even when they
are erroneously marked with a sync*, async or async* marker. This
ensures that these are verifiable.
Change-Id: I6d5bed9305129c47306ad9fd0e248683a6577800
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/307804
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
This allows us to keep symbol names for classes/methods/fields - even if
obfuscation is enabled, but has no other effect on tree shaker / ...
For go/dart-ama
TEST=vm/dart/keep_name_pragma_test
Change-Id: I66c0fc32217d9180f821658bae463f2c1d7fb1af
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/309740
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Auto-Submit: Martin Kustermann <kustermann@google.com>
In a future CL, I plan to refactor some of the flow analysis API so
that the CFE can supply subexpressions to flow analysis before they
are lowered, rather than after. This should help reduce the risk of
bugs where lowering leads to type promotion being lost
(e.g. https://github.com/dart-lang/sdk/issues/52183).
The refactor I'm planning will be easier if there are no calls to the
flow analysis API within flow analysis itself, so to prepare for it,
this CL moves the body of `FlowAnalysisImpl.functionExpression_begin`
to a private method, and updates both `functionExpression_begin` and
`lateInitializer_begin` (which use the same underlying logic) to call
that private method.
Bug: https://github.com/dart-lang/sdk/issues/52189
Change-Id: I1185418225b8a402670e6eece6599c326fdc234a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/309440
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
If again and again editing, say, a `pubspec.yaml` with proper timing
there is a "temporary leak" that repairs itself once the analyzer
finishes (some time after the editing stops).
What happens is that old contexts are saved in the
`declarationsTracker` but eventually cleared in the
`afterContextsCreated` call.
In a test on Windows (on Linux I'd currently run into
https://dartbug.com/52703) I opened the entire "pkg" folder and edited
a `pubspec.yaml` file every 5 seconds.
The analyzer went from using something along the lines of 700MB of heap
to using around 2.5 GB of heap after 25 edits and 17GB (!) of heap
shortly before stopping at 250 `pubspec.yaml` edits.
After the editing stopped (and clicking the GC button in observatory)
the heap usage went down to ~650MB heap used.
This fixes the problem by clearing the `declarationsTracker` on the
`afterContextsDestroyed` call too. In the same test it stays at around
300-700MB of heap.
Possibly related to:
https://github.com/dart-lang/sdk/issues/48788https://github.com/dart-lang/sdk/issues/52447
Change-Id: Ia38cc946a1f36fa8c5b6804f79cbc8dd96c21030
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/309722
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
