If a script uses `Platform.script` running it with as `dart
<script.dart>` and `dart run <script.dart>` would give the correct
script ("<script.dart>"), but running it with `dart run -r
<script.dart>` would report a dill file in the temp directory which is
not only surprising, but also breaking and for instance running the CFEs
strong_suite.dart via `dart run -r` didn't work.
This CL introduces --script_uri_override to the VM and makes the
resident compiler setup pass it so that when running `dart run -r
<script.dart>`, even though the vm is actually launched from a dill file
that resides in temp, `Platform.script` will actually return
`<script.dart>` - and running the CFEs strong_suite.dart via `dart run
-r` now actually works.
Tested: Added pkg/dartdev/test/commands/run_test.dart and manual testing.
Change-Id: Ia65c01834485fe06af63584baf0448dd5b9ffdb4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/510343
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
This removes the initializer property on InternalVariable together with various other internal delegations to the astVariable to make sure the InternalVariable is behaving has a normal InternalTreeNode.
Change-Id: I1f8469eeb3f80d815f3bb5676bf43e66067b82ca
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/510841
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Recognize a second operand if its `ToUint32` is `0xFFFFFFFF`,
not just the exact value. This includes fx `& -1`, which is output
by `toUnsigned(32)`.
Change-Id: Ieccb42591efd72b4aae62a7c6e678f05510abdc6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/510960
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
This updates the InternalVariable hierarchy to be based on a sealed base class InternalVariable with no connection to IVariable. IVariable is removed and unused properties of InternalVariable are removed.
TEST=existing
Change-Id: Iacfbe9ab21d1c9aab043712099cd1ee6e4cee174
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/510825
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This adds an InternalLegacyVariable the doesn't derive from LegacyVariable. This fully separates InternalVariable from Variable and assigned variable tracking and flow analysis is now changed to used InternalVariable instead.
TEST=existing
Change-Id: Ida9dc78d4f0e3fab3baf7a965273e1ddf68a80b8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/510341
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Now that we have a way to tell binaryen to inline functions (see [0],
which added support for `(@binaryen.inline <0...127>)` annotations) we
can tell it to inline functions that were annotated with
`@pragma('wasm:prefer-inline')`
Since binaryen sometimes can devirtualize call sites that TFA cannot, it
can then inline those devirtualized calls.
[0] https://github.com/WebAssembly/binaryen/issues/7972
Change-Id: I139bd43976a1ddb83afe756d4fbac09419f7199e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/510822
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Binaryen introduced `binaryen.inline` which allows us to tell it
inlining hints now, including "never inline" hint (see [0])
This allows us to remove the ugly mangling of wasm function names with
`<noInline>` postfix.
We also now pass `--strip-toolchain-annotations`: The annotations
occupy size in the wasm binary and wasm runtimes ignore them (they are
for `wams-opt` only).
Except for IR tests: Here we want to see the annotations, so we keep
them there.
We also rename the package:wasm_builder classes to clearly indicate
those are binaryen specific sections.
We also make the ir_test.dart put it's options first, allowing the IR
tests to override options if needed.
[0] https://github.com/WebAssembly/binaryen/commit/3c25487214600a9
Change-Id: I96688bfaeba403a39cd5e7376f8d2889bcbae030
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/510000
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
This makes tests more reproducible, and makes it easier to copy commands between workspaces, or between a failing bot and a local workspace.
Change-Id: Ic8dd10a3540f314a406e5c5b0a23d97032e5d01d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/508364
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
The experimental `dart:ffi` support predates deferred loading
implementation. Any use of FFI features would lazily import `ffi.memory`
into the (fixed coded) main module.
This CL now lazily imports the `ffi.memory` module into all modules that
operate on the memory.
=> This will now allow a flutter app that is compiled with dart2wasm
in deferred loading mode to possibly defer parts of flutter
engine code that uses FFI into deferred modules.
Issue https://github.com/dart-lang/sdk/issues/56952
Change-Id: Idf821ce2dd92c36ac1be9dae24307516a1ae86d9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/510760
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
'canInvokeTypeEquality' was assuming that if a single case was a Type expression, then type equality should be used for the whole switch statement. This is incorrect because if a single case is a type expression but the rest are, for example, ints (as in the fixed test) then the int cases should be compared with identical while only the type expression should be compared with ==.
More importantly, the expected type of the case expression constants should be top type rather than the Type type. Top type is the union of Type and the other case type.
Switches that only include Type expressions will now use "top" type as well but in general switching on a Type expression is an antipattern we shouldn't optimize for. And the impact of not specializing the switch type to Type should be very minimal.
Fixes: https://github.com/dart-lang/sdk/issues/63476
Change-Id: Ib96172f157d8cf3093199e5127d4835e7b25011c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/509920
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
When generating SSA jump instructions (HContinue and HBreak) for AST break statements, ensure that we only select labels from the target's label list that are explicitly marked as valid continue (isContinueTarget) or break (isBreakTarget) targets.
Previously, handler.labels.first was selected indiscriminately if non-empty, which caused unlabeled continue statements inside loops that had an outer break label to incorrectly generate labeled continue jumps targeting the break label.
Fixes: https://github.com/dart-lang/sdk/issues/63456
Change-Id: Ic497776141a192edb0930f4585cdaae2feecb3d5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/510280
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
The lint will fire even when there is a comment in the body, such as
```dart
class C() {
this { /* comment */ }
}
```
I think this is the right behavior because I can't think of any useful
comment that wouldn't be better somewhere else, but let me know if you
disagree.
This doesn't yet have a fix, but it should.
Change-Id: Ia5ffa6b06c75a6a7400ec32a9d22209c08a9c73d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/510401
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
For clients outside the library the useful property in
`FormalParameterElement.type`, not *how* this type was specified
syntactically: `void f(int a<T>())` vs. `void f(int Function<T>() a)`.
This way, we have to think about these type parameters and formal
parameters only locally, like for example about local variables - they
exist, enclosed in a fragment, but don't leak outside into the element
model of a method.
I found this while working on the augmentations: that formal parameters
have to have the same types in the introductory declaration, and in
augmentations.
Change-Id: Ie4e92ebd0cd0204c4ba80200a9497e95859cc3e7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/509522
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Konstantin Shcheglov