Use `Object.hasOwnProperty()` to test for the presence of named
arguments when the argument name matches a property from the
native JavaScript Object prototype. This is slower but more
accurate because it does not find any properties up the prototype
chain.
Previously, named arguments could falsely be detected as passed if
the name matched one of the properties on the native JavaScript
Object and an incorrect value would be retrieved from the named
argument packet.
This change also deletes the `@undefined` annotation because it
was only used in places that were not read by the compiler and
only read by the compiler in places it wasn't used. Essentially
dead code.
Fixes: https://github.com/dart-lang/sdk/issues/56315
Change-Id: Iedeacb1e7d61234fc63605d6df05da977c9a456e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/377721
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
- All members that are currently only called within the library are
now private.
- Remove some unnecessary getters and just access the private fields.
- Update some fields to be final and provide an initializer on the
constructor.
Change-Id: I6183cc4452bc740150c0dce4137cee518cf8b280
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/376520
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Nate Biggs <natebiggs@google.com>
- Copy members from `SharedCompiler` into `ProgramCompiler`.
- Delete `@override` annotations from the `ProgramCompiler`
members that are now the only implementation.
- Delete abstract members that were part of `SharedCompiler` and
copy the doc comments to the actual implementation.
- Delete unnecessary getters and just access the private field:
- `_symbolContainer`
- `_incrementalMode`
- Copy body of `super.setIncrementalMode()` into the call site.
- Copy all other members from shared_compiler.dart into
js_utils.dart.
- Fix imports and namespaces accordingly.
Change-Id: Ia94434a6f01a58bac4e1eb05a4414243dade6de4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/376280
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Nate Biggs <natebiggs@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
This reverts commit d84f908641.
Reason for revert: Causing internal failures.
Original change's description:
> [ddc] Update DDC compiler to start using the new async transform.
>
> Updates compiler.dart to use the new async transformation.
>
> Some key things to note:
> - Dart Let and BlockExpression expressions are represented as IIFEs in DDC compiled code. For non-async code this works fine but this doesn't work when they contain "await" expressions. When these expressions contain awaits we use the same lowering as we would for an async function, but instead apply it to the IIFE function. Then we simply await the IIFE Call expression as the IIFE will return a future after the transform.
> - For async/sync*/async* functions we want to make sure parameter initialization happens synchronously before any of the async logic is hit. To do this we first apply the async transform the user-code function body. We then prepend the paramter initialization logic to the body of the transformed function.
> - We add support for JS_RAW_EXCEPTION which allows the machinery in async_patch to access the wrapped JS exception in a catch block rather than the unwrapped Dart exception.
> - Stacktraces and sourcemaps have some differences. There is still room for improvement in these but they should at least allow users to reasonably step through parts of the async code.
>
>
> There are also several test fixes/updates associated with this change. The test_runner wrapper no longer has to inject in asyncStart/asyncEnd calls, these are handled by the new async logic.
>
> Change-Id: I0f9f547cd9eb52ff7d850d277876d4d57568a14e
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/374444
> Reviewed-by: Bob Nystrom <rnystrom@google.com>
> Reviewed-by: Mark Zhou <markzipan@google.com>
> Reviewed-by: Johnni Winther <johnniwinther@google.com>
> Reviewed-by: Nicholas Shahan <nshahan@google.com>
Change-Id: Ia939fe5a9dfd3a5031b06a7ea26c52e58b89f011
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/375701
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Jake Macdonald <jakemac@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Mark Zhou <markzipan@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Updates compiler.dart to use the new async transformation.
Some key things to note:
- Dart Let and BlockExpression expressions are represented as IIFEs in DDC compiled code. For non-async code this works fine but this doesn't work when they contain "await" expressions. When these expressions contain awaits we use the same lowering as we would for an async function, but instead apply it to the IIFE function. Then we simply await the IIFE Call expression as the IIFE will return a future after the transform.
- For async/sync*/async* functions we want to make sure parameter initialization happens synchronously before any of the async logic is hit. To do this we first apply the async transform the user-code function body. We then prepend the paramter initialization logic to the body of the transformed function.
- We add support for JS_RAW_EXCEPTION which allows the machinery in async_patch to access the wrapped JS exception in a catch block rather than the unwrapped Dart exception.
- Stacktraces and sourcemaps have some differences. There is still room for improvement in these but they should at least allow users to reasonably step through parts of the async code.
There are also several test fixes/updates associated with this change. The test_runner wrapper no longer has to inject in asyncStart/asyncEnd calls, these are handled by the new async logic.
Change-Id: I0f9f547cd9eb52ff7d850d277876d4d57568a14e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/374444
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Mark Zhou <markzipan@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
To make review easier I've broken out adding the transformation code into a separate change without referencing it yet. A few other changes had to be included with this. Nothing in this CL changes the behavior of DDC yet.
While the rewrite_async.dart file is largely copied from the dart2js version, there are some significant differences:
- The dart2js version uses a "safeName" function hooked into the Namer to assign variables unique names that avoid collisions/shadowing. DDC doesn't have a pre-processing namer like dart2js so instead I made use of TemporaryIds to achieve the same result. TemporaryIds are referenced-based names and they are assigned names by the LocalNamer when the JS is getting printed. This resolves any scoping issues that would come from the variable hoisting the transform does.
- Dart2js doesn't use for..of loops in JS but DDC does. I had to add a lowering for for..of loops that uses the [Symbol.iterator] on the loop iterable and then uses the same lowering strategy as normal for loops.
- Assignment of sourceInformation objects had to change a bit to create a better debugging experience. The source maps still aren't perfect but this is something we can improve on over time.
This also introduces a JS ast Transformer that allows the AST to be modified using the visitor pattern. Since the tree is immutable we create copies of the nodes in the tree. This is slightly expensive but since we only ever process a single member at a time, this should be okay.
Change-Id: I91da1afce4d6649e8177b36ddde098505a24e927
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/374540
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Mark Zhou <markzipan@google.com>
This allows internal Set classes to be referenced by our runtime.
Context: incoming changes to our generic types (required for hot reload) requires that RTIs be passed to generic classes on instantiation. Moving our Set implementation into our private runtime and making their classes public allows us to directly reference them without clobbering names externally.
Change-Id: Ie47b3263ebbf2650d314b5285a2d50f3abd1a664
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/373327
Commit-Queue: Mark Zhou <markzipan@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Late local variables are lowered by the CFE into a local:
* backing store variable
* get method
* set method
* isSet local variable (optionally when the type is nullable)
This change updates the name in JavaScript used for the backing store
variable to match the name for the late variable from the original
source. It also updates the scope information passed for expression
evaluation to remove the lowered name and replace it with the original
so evaluations will work as well.
The name change avoids the hiding performed by the debugger on
recognized temporary names so it appears in the list of local variables.
b/343405209
Issue: See https://github.com/dart-lang/sdk/issues/55918
Change-Id: I6b65a62baf6f26f6e9cfee9f14667d021e16645e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/369506
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Today, support for expression evaluation in DDC uses a lot of
information. To properly support compiling expressions in arbitrary
frames, we consume source-maps, module metadata, and full kernel
components at various stages of the process. This data is already
plumbed and available for non-sdk modules in our debugging systems
(frontend-server, webdev, g3), however it is not available the Dart
SDK module itself. Because of that, the expression compiler today
rejects all expression evaluation requests when the target is a Dart
SDK library.
Until the fix the availability of this data everywhere, we believe
we can support a limited form of expression evaluation: only
evaluation of libary level expressions. Basically, expressions
where scope data is not necessary and kernel outlines are sufficient to
compile the expression.
Here we introduce logic to recognize the first offset location of a
library, which is a clear indicator that no scope data is needed and
a library level expression evaluation is being requested.
This change is an attempt to help resolve
https://github.com/flutter/devtools/issues/7766. Note: just like
changes were needed here in the worker and test-compiler files, it
is possible that some change may be necessary in dwds and other
parts of the pipeline. Additional validation will be needed after
this lands.
Change-Id: Iff081a24ecb05092407279a0a7ed3d38c13cf41d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/367981
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
* Add special handling for String concatenations so the first string
gets mapped correctly and work better in sound null safety.
* Update variable assignments to more consistently point to helpful
locations, specifically when lowered from a prefix increment like
`++x`.
* Run the sourcemap and stacktrace test suites with sound null safety.
Previously these suites were running with unsound null safety so more
operations were wrapped in function calls to check for null. Those calls
allowed for mode step or break points that hid some of the issues
addressed in this change.
Issue: https://github.com/dart-lang/sdk/issues/55692
Change-Id: Ibd887c8da64e72ab84c0698dd49b845abfaedbb8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/366025
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
All uses either already pass a non-nullable String or assert that
the returned value is non-nullable which would be equivalent to
asserting that the value passed is not null.
Change-Id: I6308a8b39bc5ee08db6741145ed7b8a983c33118
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/365662
Reviewed-by: Mark Zhou <markzipan@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Only run these tests with sound null safety. Follow up changes will remove more tests configurations, and null safety mode plumbing for
the DDC infra.
Change-Id: I0b511d778e54da2a8f5140c4a00b36eefb8000ac
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/365540
Reviewed-by: Mark Zhou <markzipan@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
The first in a series of changes that deletes all DDC tests running
with unsound null safety. Follow up changes will remove more tests
configurations, and null safety mode plumbing for the DDC infra.
* Delete the unsound version of some suites.
* Renames the sound suites to be more descriptive of the code in the
test instead of the mode it is run in.
Change-Id: If2edfecc811bb78a77a1e93bd6d0b75f22c3e80c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/365520
Reviewed-by: Mark Zhou <markzipan@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
* Extends the frontend server controller to validate/reject compile errors in compiles/recompiles.
* Extends the config to permit an 'expectedError' entry.
* Adds a handful of tests to the suite (adapted from the VM's hot reload tests).
Change-Id: I47d814e375c4c72d0406ebf5bdfee3f1975c64f0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/363800
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Mark Zhou <markzipan@google.com>
With the new type system type arguments appearing in extends are
no longer represented by a class definition and do not need to
trigger any lazy logic.
Change-Id: I3f80f9f972bec69c678909c12d25a604a8fe2c59
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/353205
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Mark Zhou <markzipan@google.com>
If DDC is invoked with an relative output path during the Dart SDK build
itself rather than an absolute path, then the build will fail with an
error message that it can't calculate the relative path between the
output file and the source map. The problem is that p.url.relative
cannot be used with real relative filesystem paths as the current
directory is assumed to be the string '.' rather than the actual
directory and the algorithm cannot perform the resolution.
This change blocks the RBE dart action offloading in a follow up change,
which changes the Dart SDK build to only use relative paths when
building on RBE, which otherwise fails in the above manner.
Fixes: b/333765428
Change-Id: I5f3d984337cdd006feeb6b721f21fa17ed0d23f5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/362189
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Auto-Submit: Jonas Termansen <sortie@google.com>
Commit-Queue: Jonas Termansen <sortie@google.com>
VM hot reload are run via:
1) We first emit a dill for every generation ahead of time (full dill on gen 0, incremental deltas subsequently).
2) We start a VM process at generation 0.
3) The VM process runs until it hits a `hotReload` command. It then uses the VM service protocol to connect to itself and reload the next generation.
4) The VM exits when the next generation isn't found.
* Adds config files to reload tests that allow runtime filtering.
* Implements VM-side hot reloading
* Adds several VM-specific hot reload tests
Change-Id: I1c6ad5c4eed426a0189c1b4af31297c9c1dba717
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/359200
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Mark Zhou <markzipan@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
When running in d8 the runtime flags need to be set by loading an
SDK with the same name passed for the application that gets used
when the application is started. If not the module system will
create an additional instance of the SDK module. This meant the
runtime flags were being set in one instance while the application
read them from another.
The same issue was present in the ddb script and this change fixes
it there as well.
Add the `--interop-null-assertions` option to the ddb script that uses
the runtime flag to enable null checks on non-static JavaScript
interop APIs.
Issue: https://github.com/dart-lang/sdk/issues/55378
Change-Id: Id8c31383fa601f5953e2cc41021746aa918186b7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/361133
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
- Add a runtime flag to enable checks on non-nullable APIs that
return values from non-static JavaScript interop.
- Call a new helper method at the call site when these APIs are
detected to perform the null check.
- Add test file for the cases we can detect and enforce.
NOTE: This does not make non-static JavaScript interop sound.
This only adds more checks to enforce soundness with respect
to nullability in some cases. There are still holes that will
never be closed due to the permissive nature of this form of
JavaScript interop.
Change-Id: I2f88d1543a683fdc84d764e2b0eaafeb0ca73107
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/358581
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
In the refactor to speed up this test, we removed most retry logic
(except for the "unreliable tests" that now apply retries in a
predictable manner).
The "noisy" tests have a similar behavior but for different reasons.
These put a lot of timing presure by serving hundreds of very large
files. The default response timeout of 5s trips this sometimes.
We could try to make this more predictable by providing a larger timeout
upfront, but I believe part of the intent with these tests was also to
incorporate retries for reasons like response timeouts. So instead, I've
added a retry, which will use by default a larger timeout on the second
attempt. This will hopefully be sufficient to remove this source of
flakiness.
Change-Id: I8eb5e9dceed5e7af36f6db45147c2d961247f6e2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/360503
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
This test was flaky about 3% of the time in linux bots due to a race
condition. Details are shared in
https://github.com/dart-lang/sdk/issues/55299. TLDR, when one test case
completes and it's execution is resumed (program 1), the test driver
sets up a breakpoint for a new test case concurrently and schedules to
run main again (program 2). Depending on when the breakpoint is set, it
could be hit by either program 1 or program 2. If both programs are in
the same state when they hit the breakpoint, then it doesn't matter
which program we use to validate the test expectations (a benign race
condition). However, this is problematic when the state is different,
which can happen when test 1 and test 2 both are using the same
breakpoint in a loop. This is what happened for the `forLoopTestBP` in
this CL.
To workaround this data race between two test cases, I decided to simply
combine them into a single test case. A different alternative is to copy
the test function and use a different breakpoint, but that didn't seem
worthwhile in this case.
Change-Id: I561c2a25d33d56a8543fe061342cab9cceafd4e4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/359721
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Currently our end-2-end tests create a temporary folder and delete
it after the suite has completed. Only one folder is created for the
entire test run, so the deletion only gets scheduled when the entire
suite has completed.
On windows bots, the cleanup very often fails causing up to 40%
flakiness on some tests.
This CL keeps the cleanup logic as is, but will now deem tests as
passing even when we can't do the proper cleanup.
Change-Id: I8e2e2d39d1bbdaf48c138c0a05a9a2540345fc28
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/359760
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
* Adds tests for the memory filesystem
* Enables hot restart/reload tests
* Adds flags to the hot reload suite
* Makes path resolution logic windows-friendly
* Adds test-reporting logic for trybots to hot reload tests
Change-Id: Ic51a0b8a3c6f8b6de20b58b2ac185dacf444cf47
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/353788
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Commit-Queue: Mark Zhou <markzipan@google.com>
* Delete unused stuff
* rename 'path' to 'root'
* accept 'includeEndsWith' as a plain text string so we often can avoid
using regexp
* accept 'subRoots' to filter to directories faster and more precisly
than when using regexps in 'pattern'
* make 'list' async instead of async* (no more yield stuff which we
promptly turn into a list when actually using it)
Note that some changes in testing.json is not 100% semantic-preserving,
e.g. the "parser_all" suite previously had a pattern "/tests/.*\\.dart$"
which was probably meant to include all dart files in the "tests" folder
in the root, but in fact included all dart files in a "tests" folder
anywhere. The updated version does not.
Change-Id: Idd014274f86bf6214dee0753a7738ec80bc6a49e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/358442
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Nicholas Shahan