This adds support for generating truly unique fresh names when building
augmentation library code. The synthesized names are used for import
prefixes and as placeholders for not-yet-inferred omitted type
annotations.
Change-Id: I6fe9bc37b39a243c93187f561ee32e07237341f1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/237823
Reviewed-by: Jake Macdonald <jakemac@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This implements TypeDeclarationResolver for the CFE. Adds a test to
the macro api test, which includes support for throwing and catching
the ArgumentError required by the api.
Change-Id: I5bb7948064ba5a2c215289915fc10314fd28aa1d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/237020
Reviewed-by: Jake Macdonald <jakemac@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This adds support for [interfacesOf] and [mixinsOf] of the
[ClassIntrospector] interface. To support this, the mixed in
[ClassHierarchyNode] is now included in the [ClassHierarchyNode] for
a mixin application.
Change-Id: I30cef4b462b1b2b52acf1bd286d82ebc1c5caa4e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/236883
Reviewed-by: Chloe Stefantsova <cstefantsova@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>
- 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>
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>
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>
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 uses the recently added 'include' tag in libraries
specification to share common library definitions between targets
'dart2js' and 'dart2js_server' through the "private" target
'_dart2js_common'.
Change-Id: I12f85d0d71803c6adcb94e37385ba837f7cdc9ef
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/224953
Reviewed-by: Sigmund Cherem <sigmund@google.com>
This change adds a stack trace so that if the check fails, the user
sees the stack trace of the call to `checkUnassigned` prior to the
stack trace from the process of visiting the mini-AST. Usually teh
stack trace from the call to `checkUnassigned` is much more useful in
debugging, since it allows the user to see the location of the problem
relative to the code being analyzed.
Change-Id: I125b4059ec740850919798cfa66bf7e8c7490213
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/217283
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
These behaviors were introduced during the fix for
https://github.com/dart-lang/language/issues/1785, and at the time
they were tested using both unit tests and language tests. But it was
not possible to write ID tests for them, because ID tests don't
support turning on experimental language feature flags.
Now that the "constructor-tearoffs" feature has been turned on we can
test these behaviors using ID tests.
Change-Id: I6e1ccda4b5837ab61de80f15d2f31a82a90b4a22
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/212265
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Previously, the analyzer and CFE were responsible for two pieces of
logic that arguably should be in the shared flow analysis engine:
- Deciding whether or not it's necessary to tell flow analysis about
initializer expressions.
- Deciding whether or not to promote the variable at the time of
initialization (we do this when the variable is implicitly typed,
and the initializer is a promoted type variable type).
It's better to just always tell flow analysis about the initializer
expression and let it decide what to do about it.
This paves the way for fixing
https://github.com/dart-lang/language/issues/1785 (which results from
initializer expressions sometimes being ignored when they shouldn't
be), by consolidating the broken logic into the flow_analysis library,
where it will be easy to unit test the fix.
Bug: https://github.com/dart-lang/language/issues/1785
Change-Id: Iec832e92995eb4f8d0c1fbd4e9be6c897e0917b5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/211180
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Paul Berry