Results of Phase 2 macros are now applied. The macro application code
has been refactored to support that Phase 1 can apply all macro
applications within a library in bulk, but Phase 2 can apply each
macro application in sequence.
The later is to prepare for making added member visible to subsequent
macro applications within Phase 2. This functionality has not been
completed yet.
Change-Id: Idaf2702e21bde75aedb1509d88e02f270196af5e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/233380
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This also:
- Adds support to the bootstrap code to handle communicating via sendPort or stdio
- Refactors pretty heavily the isolate executor code such that it can be reused.
- Refactors the isolated executor test into a shared test for all executors
- Removes the mirror based executor entirely - I don't see a path forward with this one.
- Reorganizes all executor based files under macros/executor
Change-Id: I2fc6bb3e6ce56c8b331719f4dc08617b3a521398
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/233200
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jake Macdonald <jakemac@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>
- 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>
* 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>
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 adds an initial test for implementation of the macro api that
can be shared between implementations.
The test consists of a set of macros and a library of declarations that
apply these macros. When applied the macros work as unittest tests that
check that the macro api give the expected results for the various
declarations.
Change-Id: Id4183e8ac90fa96ef1ebc01b1c9f15cc413b6443
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/232383
Auto-Submit: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jake Macdonald <jakemac@google.com>
Commit-Queue: Jake Macdonald <jakemac@google.com>
Use `hasScheme` in place of comparing against the empty string, and
`isScheme` to compare against all other schemes.
TEST=No behavior changes.
Change-Id: Ifc9fd13c6cf37933ebd4a754c4b500dedbcb291b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/231185
Reviewed-by: Kevin Moore <kevmoo@google.com>
Commit-Queue: Nate Bosch <nbosch@google.com>
In general this moves in the direction of dealing more with Identifier instances instead of TypeAnnotation instances.
This ended up being a larger refactor than I had hoped, but at a high level it does the following:
- Adds the TypeAnnotationCode/NamedTypeAnnotationCode/FunctionTypeAnnotationCode classes
- Change the TypeResolver api to have a single 'resolve' method, which takes a TypeAnnotationCode argument
- Makes ParameterCode/TypeParameterCode take more structured arguments
- Update the CFE code to be able to resolve NamedTypeAnnotationCode instances instead of TypeAnnotation instances
- Also deletes some unnecessary Code classes.
Note that supporting FunctionTypeAnnotationCode instances looks like it will be some more work in the CFE.
Change-Id: I84712aa1c29634cd0a93d245171b3591f69be927
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/231327
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Jake Macdonald <jakemac@google.com>
Additionaly this CL moves the arguments checks for redirecting and
super initializer invocations from the early stage of their creation
to a later stage of their addition to the list of constructor
initializers, after the possible modifications to the arguments of the
invocation are performed.
Change-Id: I87a3710c885926a74c844288bdf266e7127a9c40
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/229967
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Chloe Stefantsova <cstefantsova@google.com>
Removes the `imports` field from MacroExecutionResult (we don't know them since identifiers arent resolved yet).
Adds a callback function when creating the library to convert an identifier to its library import Uri.
Change-Id: I7f4345f41aa24d18aa7872a226fcfce32166ea6c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/230400
Auto-Submit: Jake Macdonald <jakemac@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
- The only public member on Identifier is `String get name`, but implementations should tie these back to the original AST nodes they came from. These can't be created by users, only given to them.
- Replaces most name getters with Identifier identifier getters.
- Updates many apis to take an Identifier instead of a TypeAnnotation. This definitely cleans things up some as TypeAnnotation was weird for a lot of these apis that don't care about type arguments etc, only the name of the type.
- Replaces the instantiate API on TypeDeclaration with two new apis on TypeResolver:
- `Future<StaticType> instantiateType(TypeAnnotation typeAnnotation);`
- `Future<StaticType> instantiateCode(ExpressionCode code);`
- This one might be a bit weird, but it allows for a fairly intuitive way of constructing any arbitrary type (like function types with required params, etc).
- Removes the ability to pass TypeAnnotations to Code objects, now you can pass Identifiers instead. You can however call the convenience `Code get code` getter on TypeAnnotation, and pass that to a Code object. We could implicitly invoke this if wanted to, and allow passing TypeAnnotations directly again, 🤷♂️ .
- Removes the IdentifierCode class, it is confusing to have both. We already have ExpressionCode which can be used instead.
- We no longer expect setters to have a trailing = on the name - since names are no longer used to disambiguate, it is OK for two identifiers to have the same name they can be disambiguated by the AST node the originated from.
Bug: https://github.com/dart-lang/language/issues/2072
Change-Id: Ibb012d91de3da9a699b7d22fbe2bae00be9b023e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/230180
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jake Macdonald <jakemac@google.com>
- Added the ClassMemberDeclaration interface to simplify some things and unify builder implementations.
- Adds tests for running macros on top level declarations
- Update the code for executing macros to allow function/variable macros to be ran on methods and fields.
- Other general cleanup and some minor bug fixes
Change-Id: I9bc60740c1b583e39179238cdcd68a78c110c3dd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/229621
Auto-Submit: Jake Macdonald <jakemac@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jake Macdonald <jakemac@google.com>
Each request is now ran in its own zone, with its own cache of remote instances by ID. Requests and responses have a zone identifier to know which zone they should be serialized/deserialized in.
Refactor to express most internal objects in terms of Impl classes which are serializable directly, instead of using extensions.
Moved the `kind` enums to the general `RemoteInstanceKind` enum, which all `RemoteInstance`s must have.
Change-Id: I0264fe2b8cd2c2717787fa8e6318e725f63b29d8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/227902
Reviewed-by: Johnni Winther <johnniwinther@google.com>
In certain error recovery situations, it's possible for code to refer
to a variable whose declaration has been lost by error recovery
mechanisms. To prevent flow analysis from crashing when this
happened, it assumed that any reference to a variable whose
declaration had not yet been seen was valid, and implicitly added that
variable to the flow analysis state.
This created a subtle problem: if a function contained a closure that
declared (and assigned to) a local variable, at the time the closure
was entered, flow analysis would get confused and temporarily put the
variable in the "write captured" state (because it hadn't yet seen the
declaration of the variable, so it didn't realize it was local to the
closure). Then, a boolean variable might capture that incorrect
state. Later, upon seeing the declaration of the variable, it would
fix the incorrect state, however it was possible that a later
reference to the boolean variable would re-vivify the old incorrect
state. This is precisely what happened in issue #47991.
This CL fixes the problem by giving flow analysis the ability to
detect, at the time the FlowAnalysis object is constructed, all
variables that are referred to but not explicitly declared, and add
them to the flow analysis state. This allows it to safely assume that
any variables that are not yet in the flow analysis state haven't been
declared yet (and hence can be ignored), so no variable is every
erroneously placed into the "write captured" state.
Fixes#47991.
Bug: https://github.com/dart-lang/sdk/issues/47991
Change-Id: I8d84fab96fad063f1d3ade3b8b9a6e9af88c3737
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/227361
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This change adds assertions to ensure that the first phase of flow
analysis (calls to the AssignedVariables class) is complete before the
FlowAnalysis class is created. It also calls AssignedVariables.finish
(which does additional assertions) from the FlowAnalysis constructor
(if the client hasn't done so already).
Adding these assersions exposed a few minor (but benign) bugs in the
usage of the flow analysis API.
- The flow analysis unit tests were failing to call
AssignedVariables.declare. This should have been caught by
AssignedVariables.finish, but the flow analysis unit tests were
failing to call that as well.
- Several flow analysis unit tests failed to declare the variables
they were using (or in one case, the declaration was at the wrong
location).
- In the CFE, DeclaredSourceConstructorBuilder.buildOutlineExpressions
was failing to set up scopes properly when compiling a const
constructor.
- In the CFE, SourceLoader.buildExpression was failing to call
AssignedVariables.declare for variables in scope.
- In the CFE, the TypeInferrerImpl constructor was constructing the
FlowAnalysis object eagerly, even though the AssignedVariables phase
often hadn't completed yet. I've fixed this by constructing
FlowAnalysis lazily.
A follow-up CL will take advantage of the invariants checked by these
assertions to introduce the logic necessary to fix issue #47991.
Change-Id: Id680020dcd525632afa0820bc49c7b966b1ea534
Bug: https://github.com/dart-lang/sdk/issues/47991
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/227320
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This CL changes the way dart: libraries are considered supported when
used in conditional imports or bool.fromEnvironment constant using
the "dart.library.*" values.
Library nodes now has an isUnsupported flag which is set according to
the "supported" property in the libraries specification. Furthermore
the Target now supplies a DartLibrarySupport interface that allows
targets to override whether dart: libraries are unsupported.
This allows the JIT/AOT to use the same platform file but still
consider dart:mirrors unsupported in AOT mode, and dart2js to consider
the internal library `dart:_dart2js_runtime_metrics` supported.
Furthermore, the internal handling is changed so that condition imports
and bool.fromEnvironments constants are computed through the same logic
for "dart.library.*" values, avoiding the need for passing these values
through the environment.
TEST=pkg/front_end/testcases/general/supported_libraries/main
Closes https://github.com/dart-lang/sdk/issues/48057
Closes https://github.com/dart-lang/sdk/issues/47814
Closes https://github.com/dart-lang/sdk/issues/47243
Closes https://github.com/dart-lang/sdk/issues/32657
Closes https://github.com/dart-lang/sdk/issues/36460
Change-Id: Ie8f8dff99167de64ced51b71d89918bf0f3bbd13
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/227020
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Johnni Winther