- Move expression evaluation to ddc in preparation for google3
- Added server to ddc to handle update and compileExpression requests
- Added tests
- Added 'experimental-output-compiled-kernel' option to ddc to generate
full kernel files only for compiled libraries, and store with
'.full.dill' extension
- Added AssetFileSystem to communicate to the asset server in the
debugger
- Made expression_compiler_worker work with full kernel files,
so removed invalidation of current file to improve performance
- Made expression_compiler_worker reuse already loaded imports
to avoid reading them from source in the incremental compiler
- Updated tests to work with DDC (for simulating webdev)
- Disabled tests that work with bazel kernel worker for now
as it does not generate full dill files yet
- Addressed code review comments from the prototype version:
https://dart-review.googlesource.com/c/sdk/+/157005
Details:
Currently, in flutter tools, expression evaluation is supported via
expression compilation, which is done by the incremental compiler in
the frontend server. The same incremental compiler is used for initial
application compilation, incremental code compilation for hot reload,
and any number of expression compilation requests.
In google3, the apps are typically too large to be compiled as a whole
in memory by the frontend server. Build in google3 is currently done by
blaze, as a distributed build using a task dependency graph. Build tasks
output kernel outline files as an interface between components produced
by individual tasks.
We are proposing an implementation of the expression compilation in
google3 that is taking advantage of full kernel files produced by the
build (supporting build changes to follow). This change introduces a
small server based on dev_compiler, which can handle following requests:
- update: load full kernel for given modules (done on app start)
- compileExpression: compile expression in a given library and module
(done when paused on a breakpoint)
Expression compilation uses previously loaded kernel files for the
application component and its dependencies to compile an expression.
Change-Id: Icf73868069faf3a2eb6d43ba78e459f8457e9e35
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/160944
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Gary Roumanis <grouma@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Reviewed-by: Jake Macdonald <jakemac@google.com>
Commit-Queue: Anna Gringauze <annagrin@google.com>
This adds support lowering the encoding of top-level/static fields
with initializers as if they were marked as late fields. This ensures
that LateInitialization is thrown if final fields are written to during
initialization.
Closes#42956
Change-Id: I488fdddd87ebd935a0cdaf82a724e9b87d5f91ba
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/160724
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
- Wait for the file writes to complete before exiting.
- Only accept the arguments that are actually used.
- Consistently read the arguments that are passed.
Change-Id: I913b8bd35135495cb5e94e4f88555997aea42e54
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/159181
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Jake Macdonald <jakemac@google.com>
Fixes the case where libraries got renamed when created and
they are exported. Previously ddc was emitting broken code that
incorrectly used the original name in the export.
This bug was breaking some benchmarks at runtime.
Change-Id: Id8b27d645766db41fb5ccb5c74d8655dd4a5d4ba
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/157000
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Mark Zhou <markzipan@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
All of the backends (dart2js, DDC, VM) were checking if the invocation
name was tagged with "set:" and appending "=" to the name if so.
Instead, we can simply have the CFE perform this logic at the callsite.
Note that the name of the setter itself is still unchanged. Backends may
still need to generate the correct name themselves when handling NSMs
via code paths other than instantiateInvocation.
Change-Id: Iae42c849d3557be3e3b77c3af6f3993347ba0b6c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/156142
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Mayank Patke <fishythefish@google.com>
Compiled output for sound null safety mode no longer needs to check
non-nullable arguments for null.
They can't be null since we no longer allow mixed opt-in/out libraries
when running with sound null safety.
Cleanup a repeated string in the SDK.
Change-Id: Ib7ae86f04660857957b4a7590bc5a7efd2c3fa04
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154848
Reviewed-by: Mark Zhou <markzipan@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Now that the sound null safety mode is a compile time flag
instead of a runtime flag there is no need to set the value in
the bootstrapping code before running main(). The sound and weak
versions of the sdk now have it already set.
Add compileTimeFlag() method that will inline the constant value
directly into the generated output.
Change-Id: I5b9243c47cffc421067ac820ef49342b9d0efff9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154100
Reviewed-by: Mark Zhou <markzipan@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
This is the first step to removing all of the the sdks precompiled
to JS modules from the sdk download.
Enables build_runner to produce a JS file on demand from a .dill
file bundled in the sdk download. At this time, only the SDK can
be compiled from a .dill file.
Update build targets to run bin/dartdevc.dart instead of
tool/compile_dartdevc_sdk.dart.
Will delete tool/compile_dartdevc_sdk.dart after we cleanup all
of the uses outside of the SDK.
Change-Id: Id6002675419e8e502912cb3f5b626a0d13461df5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/151025
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
There should be no way this could cause an unexpected failure
or break soundness but there is no reason to be marking the type
parameter as a legacy type in the check.
Change-Id: Ib4cf22cacd78d6cb9b55dd6ed594c75aa81ceead
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/149887
Reviewed-by: Mark Zhou <markzipan@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
During expression compilation, if the compiled expression is using
a type that was not used in the current function, the incremental
compiler and DDC produce code that refers to undefined types.
To fix that, discharge types created during expression compilation
and add their definitions at the beginning of the generated
function.
Added tests to validate the behavior.
Fixes: https://github.com/dart-lang/sdk/issues/41443
Change-Id: If3fdce85a50ab2590d107f3b9e8c19b4768fd482
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/148468
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Anna Gringauze <annagrin@google.com>
For some types it makes sense to distinguish between nullability as a
property of including null and the declared nullability, such as for
type-parameter types and FutureOr types. This CL introduces the
separation between the two concepts. The plan is to use that when
implementing FutureOrType.
Bug: https://github.com/dart-lang/sdk/issues/40123
Change-Id: I90b45bea768e89c213d021d360a481d38377c682
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/147903
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Dmitry Stefantsov <dmitryas@google.com>
Currently hidden behind a flag marked experimental. We need to
define a clear API or process to introduce breaking changes before
we start landing dependencies in packages outside the SDK.
Change-Id: I27ed48c78fc3bad46be92c21c35ae91f4c036784
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/144243
Reviewed-by: Mark Zhou <markzipan@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Gary Roumanis <grouma@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
For the cases of implicit bounds like `<T>` the default value
should be `dynamic` when instantiating and no type parameter is
provided. This change fixes this cases.
For explicit bounds like `<T extends Object?>` or
`<T extends Object*>` the default values should be `Object?` or
`Object*`. This change breaks these cases by defaulting to
`dynamic`.
Filed: https://github.com/dart-lang/sdk/issues/41539
I believe this is the correct trade off right now because the
implicit bounds like `<T>` are more likely to appear compared to
`<T extends Object?>` or `<T extends Object*>`.
Fixes: https://github.com/dart-lang/sdk/issues/41301
Change-Id: I53a22cf9de2d200f628f3ac0f6b0a6b1ab9ba3fb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/143442
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Mark Zhou <markzipan@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Treats the SDK and all application code as a legacy library when
running without enabling the null safety experiment.
- Copy all changes from the SDK fork and applies them to the existing
SDK (except the null safety syntax used in the library itself.
- Start emitting legacy types.
- Add a work around to avoid ever creating legacy or nullable versions
of types in the dart:_runtime library or in JS contexts. This should
be safely removed once the SDK is opted in to null safety.
Fixes: #40266
Change-Id: I6a029b676c3e35980a6bab876a348c35590df92d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/142904
Reviewed-by: Mark Zhou <markzipan@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Also add `legacyTypeRep<T>()` that is similar but performs
a shallow conversion to a legacy type.
Using this in compiler/dartdevc_native/ tests gives a better usability
instead of constantly wrapping and unwrapping types. It allows us to
avoid stripping off the legacy from a type when calling `wrapType()`.
Issue: https://github.com/dart-lang/sdk/issues/40266
Change-Id: I07225f18c253222b31203b0b110233a3e018a7d0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/142547
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
This allows us to start experimenting with the legacy module format in flutter web/internal.
This also updates the DDC module name parsing to throw an ArgumentError on invalid formats, and exposes the parsing method.
Change-Id: I4ce85ecd4078a9827aba046e34425a4f1d1e9abd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/142263
Commit-Queue: Jake Macdonald <jakemac@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
This is only changing the names that appear in the JS source and
should not change the runtime semantics. Prepends "_N_" and "_L_"
to nullable and legacy type names.
Function types get their markers prepended to the word "To". For
example a type `int Function(String)` in a legacy library would
have a name in JS like "_L_String_L_To_L_int".
Change-Id: I26416e2c7396806f0ff9b3d36cd915f49d48d1cf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/140366
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
FutureOr<Object> --> Object
FutureOr<Object>? --> Object?
I don't believe this to be breaking because in the current SDK
nullable types do not yet exist, and we already landed the change
to normalize FutureOr of a top type. Right now Object is still
considered a top type.
Issue: #40611
Change-Id: I83cb06db9e4bca8cb9b2c041a044904eb1080d2e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/139031
Reviewed-by: Mark Zhou <markzipan@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Unlike non-nullable types, the purpose of the annotation in
our runtime is to ensure we don't generate extra checks. This
should remove a few nullFailed calls in the generated sdk.
Change-Id: I7b8ac012a6cfa5f8baf2667d89185e7540320ec2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/138783
Reviewed-by: Nicholas Shahan <nshahan@google.com>
This flag is unused and the behavior it enables was only useful along with
`dart:mirrors`.
- Remove the flag and the field on the options object.
- Prune code branches that are no longer reachable.
- Remove or inline some functions that became either empty or trivially small.
- Remove the manual check for a `dart:mirrors` import since this is handled by
the CFE now.
- Remove references to the flag in tests.
- Remove test files which only existed to enable the flag for other tests.
Change-Id: I21bf594271fb4eeb5b73fcbf07da736e9e8d1f33
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/138018
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Nate Bosch <nbosch@google.com>
Auto-Submit: Nate Bosch <nbosch@google.com>
Because we cache on instances of type objects, all "type"-ish constructs in DDC must be pre-initialized if we want to avoid any hasOwnProperty checks (which are slow).
1) We now consult legacy/nullable caches earlier when wrapping types, as the downstream logic can be much slower than a lookup.
2) We cache on nullble and legacy wrappers themselves as well as just the underlying object (formerly we cached on just the latter) for faster lookups.
3) We attach local caches upfront, maintaining monomorphicity during hot code paths.
This improves regressions for opt-out worst-case tests from (120 us -> 2100 us) to (120 us -> 500 us) and weak mode tests from (120 us -> 1100 us) to (120 us -> 330 us).
Change-Id: I98a26064404e746162ca3feb22b0993c3b39e63c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/138330
Commit-Queue: Mark Zhou <markzipan@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Anna Gringauze