This is work in progress. Several language features are still
unimplemented or only partially implemented.
Instructions for running the compiler and its output can be found in
pkg/dart2wasm/dart2wasm.md. These procedures are preliminary and
expected to change.
The best version of d8 to use for this version of dart2wasm is 10.0.40,
as explained here: https://dart-review.googlesource.com/c/sdk/+/232097
This commit also adds a dart2wasm-hostasserts-linux-x64-d8 testing
configuration to run the compiler over the test suite.
The history of the prototype that this is based on can be seen here:
https://github.com/askeksa-google/sdk/tree/wasm_prototype
Issue: https://github.com/dart-lang/sdk/issues/32894
Change-Id: I910b6ff239ef9c5f66863e4ca97b39b8202cce85
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/175728
Reviewed-by: Joshua Litt <joshualitt@google.com>
Commit-Queue: Aske Simon Christensen <askesc@google.com>
This adds support for the generating a synthesized augmentation
library for each library in which phase 1 macros were applied.
Current implementation piggybacks on the patch library support. The
intension is that both patches and augmentations are handled through
the same general mechanism. For now, the wording refers to augmentation
libraries as patch libraries where the implementation is shared.
Testing is extended to verify that the generated classes are
included in the resulting AST.
Change-Id: Ie0d4cfdc84b55ca87e0014794f14b38e442f08eb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/233101
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
These appear to be no longer necessary.
Change-Id: I8ec8a13394b6e56697de3ccee3a5326b149a137a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/233000
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Joshua Litt <joshualitt@google.com>
- Support TransferableTypedData in the bootstrap code and IsolatedExecutor.
- Also removed the fake executor and conditional import. Mode will likely be chosen based on factors other than just the availability of `dart:isolate`.
- Run the tests in both serialization modes.
Change-Id: I5c731d192c0d3a8cdc5f7fb900dc07a32f4f4d51
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/232981
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Auto-Submit: Jake Macdonald <jakemac@google.com>
Commit-Queue: Jake Macdonald <jakemac@google.com>
Previously, when the migration tool encountered a built_value
`@nullable` annotation, it removed it, because when the built_value
code generator is consuming a library with null safety enabled, it
relies on the presence of a `?` to determine nullability, rather than
an annotation. However, there was no logic to actually ensure that
the `?` would actually get introduced, because I thought the code
generated by built_value would always create the conditions necessary
to convince the migration tool to introduce the `?` using its normal
graph traversal algorithm.
It turns out this is not the case: when `@nullable` appears in an
interface class that is used by other built_value classes, but is not
itself a built_value class, the migration tool sometimes doesn't have
enough information to figure out that it needs to add the `?`.
So in this CL, I'm doing what I probably should have done in the first
time: adding the necessary logic to the migration tool to ensure that
the `@nullable` annotation gets translated into a `?` regardless of
whether it is required to by generated code.
Bug: https://buganizer.corp.google.com/issues/217863427
Change-Id: I9efe5241634389981a4c56e764bac91b3350c4fb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/233003
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This CL cleans up some indirection now that we only support
KernelFrontendStrategy.
Change-Id: Iaee8d41e061cc88957cae00d61111cbd8c076d65
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/232963
Reviewed-by: Mark Zhou <markzipan@google.com>
Commit-Queue: Joshua Litt <joshualitt@google.com>
Remove dead phis including back-edges and cycles.
Add a postcondition validation for optimization phases.
Add post-phase validation test for dead-phi removal and dead-code elimination.
Bug: https://github.com/dart-lang/sdk/issues/48397
Change-Id: I178cda52dd165e825b9e2d9ae642c22162cee2e3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/232782
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
This indirection is no longer needed.
Change-Id: Ic917ec758dc8a8a648fea9f74ddf75f47b6b9d4d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/232485
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Joshua Litt <joshualitt@google.com>
The bad codegen reported in #48383 was due to an unused phi confusing
the expression-tree construction algorithm. It was trying to generate
data = cond ? callWithSideEffects() : null;
but `data` is unused, so somehow we generated only
cond;
We should not have unused phis at this point so I put a safety check
in the above code to not try to build an unused conditional, and
changed the dead-code eliminator to eliminate dead phis.
Now we get
if (cond)
callWithSideEffects();
I compared the output for some large apps and there were about a dozen
changes. All looked like improvements, e.g. not assigning to an unused
variable. There was some code missing that is now present, but luckily
for the large apps, it was all code that did not have real-world side
effects.
Fixed: 48383
Change-Id: Id7b32cfa0cbfb47a4d9eff174ad9ae52da99f6a4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/232781
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
* Add team "groups" in tools/OWNERS_<group name>.
* Add top-level OWNERS as a fallback.
* Add OWNERS for all top-level directories.
* Add OWNERS to all packages.
For additional background information see go/dart-sdk-owners.
TEST=No op until code-owners is enabled.
Bug: b/200915407
Change-Id: I7fe6116cc599c749cd50ca16151d6d6a801d99d7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/229147
Reviewed-by: Jonas Termansen <sortie@google.com>
This CL add support for identifier resolution to use the
MacroExecutor.buildAugmentationLibrary for generating the code.
The CL updates the ResolvedIdentifier to have a nullable [uri] in
order to support built in identifiers, such as `void`.
Change-Id: I9436ea77c06cf5618f1977f4c9ac0490ff059587
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/232623
Reviewed-by: Jake Macdonald <jakemac@google.com>
Auto-Submit: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
The class is no longer used in Dart 2.0 where instantiating an abstract
class became a compile-time error.
The class is now also exported from `dart:mirrors`. Since `dart:mirrors`
throws this error when trying to call a constructor mirror from an
abstract class, it needs to keep having an error to throw.
For backwards compatibility, we'll keep using the same class,
but restrict it to `dart:mirrors` and remove it from `dart:core`
when possible.
Q.v. #30771
Bug: https://darbug.com/30771
Change-Id: I2eef6ff8b1509b00b0567cc1951ae9972c87c3fb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/232605
Reviewed-by: Nate Bosch <nbosch@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
There are two kinds: which we just built, and from readers.
With this change we will cover also just built libraries.
Change-Id: I67fa8ec5eeb00e539b4bd648d35b547dea8b4a7e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/232686
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
With the optimizations suggested this does now equal or outperform the JSON serializer in all scenarios, the latest numbers from the benchmark are as follows:
Isolate.spawn + SerializationMode.jsonClient: 0:00:00.041666
Isolate.spawnUri + SerializationMode.jsonClient: 0:00:00.069551
Separate process + SerializationMode.jsonClient: 0:00:00.177171
Isolate.spawn + SerializationMode.byteDataClient: 0:00:00.040990
Isolate.spawnUri + SerializationMode.byteDataClient: 0:00:00.059319
Separate process + SerializationMode.byteDataClient: 0:00:00.080008
Change-Id: If5431513c7487d8b7af350381e794cbd61c1be42
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/232027
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Auto-Submit: Jake Macdonald <jakemac@google.com>
Commit-Queue: Jake Macdonald <jakemac@google.com>
This strategy is no longer necessary with the single frontend, and
inlining all the logic makes the code much easier to follow.
Change-Id: I73995aa6249b52a932dbfb2d459c2d6633a620d2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/232029
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Joshua Litt <joshualitt@google.com>
This is a reland of e77ea8a17b. I've
undone the change to the name of the platformScript setter, restoring
the previous behavior of accepting anything and casting.
TEST=Existing tests.
Change-Id: I7e36935ef3784035769527dc5624191f38faaa40
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/232487
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Leaf Petersen <leafp@google.com>
This enables the check for primitive equals in switch cases in
legacy libraries.
Change-Id: Iddc464f39525d5167a5c6e8c40c95acc3c245d76
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/231701
Reviewed-by: Joshua Litt <joshualitt@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
As we discussed some time ago, it is not clear to me where some
tests should go. Here, I put it into "location" tests, and checked
locations that seem strongly associated with the enum - its header,
its body; including the `WithClause` on the enum.
It is less clear where tests for completion inside the header or
the body of a method inside of an enum should go. I initially
planned to put them into `declaration/enum_test.dart`, but now
starting to doubt. The tests there are currently for using an
enum from outside.
Change-Id: Ife091f82bbb0ad1f26df984be42aa93a78595816
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/232421
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Annotations that refer to named constructors are represented a little
strangely in the AST, with Annotation.name being bound to a
PrefixedIdentifier and Annotation.constructorName being bound to
`null`. This was confusing the EdgeBuilder, causing it to visit the
class name as though it were an expression, and then crashing because
there was no associated expression type.
The solution is to simply not visit Annotation.name at all, because
there's no way it can have any effect on null safety.
Bug: https://buganizer.corp.google.com/issues/217386404
Change-Id: I2baf0a9e8d63a4a5bbff1b2c5ee2aeec52b2844a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/232031
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Previously, when upon reaching the integer literal, we would check if
the parent was a PrefixExpression with an operator of `-`, and if so,
use the context type of the PrefixExpression to decide whether to do
an int->double conversion. This CL moves the logic to the
PrefixExpressionResolver; we now pass down the appropriate context
when visiting the integer literal.
This makes the context handling for negated integer literals less of
an odd exception.
This is part of a larger effort to elimiate the use of
InferenceContext.getContext and InferenceContext.setType entirely.
Change-Id: I6ca63df1adcb706011c146c80c2576814a73926d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/231326
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The specification now says that `class Enum` is extended, and
has `external` impelementations of `index` and `toString()`.
Change-Id: I6cb138013722006d570766b87c46ac1c12273dee
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/232233
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
