In some cases, such as file system exceptions, ExpressionCompilerWorker
fails to start but does not close its receiver port, which causes the
consumer to wait indefinitely for responses.
Make ExpressionCompilerWorker communicate the failure to the consumer,
close the receiver port, and exit.
Added tests to verify graceful exit.
Issue that uncovered the bug: https://b.corp.google.com/issues/183218372
Change-Id: I54a9c3620cfc5f77c101b26b4e98b6eeb03ad7e1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/192260
Commit-Queue: Anna Gringauze <annagrin@google.com>
Reviewed-by: Gary Roumanis <grouma@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
- 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>
Also actually compare the SDK summary digest instead of assuming it doesn't change.
Most of this logic is mirroring logic in the bazel_worker.dart file that kernel uses, which eventually we should unify.
Change-Id: If33af0d8de0b0a6a17081dcd852dd036c4b34a82
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/107184
Auto-Submit: Jake Macdonald <jakemac@google.com>
Reviewed-by: Vijay Menon <vsm@google.com>
Commit-Queue: Jake Macdonald <jakemac@google.com>
Previously 36% of overrides were annotated, including inconsistent
annotations within a single class.
- Add annotations on remaining overridden methods.
- Add linter section to `analysis_options.yaml` so that missing
annotations are visible while editing.
Change-Id: Ief1a6d5b8da6f4b630a6cfc72a6ed67db346c081
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/103140
Reviewed-by: Vijay Menon <vsm@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
TL;DR: Unbind canonical names doesn't do what you think it does and
probably shouldn't (ever) be used. This CL stops using it in a few places.
Longer version:
When loading a dill file it:
- First loads the table of canonical names. These have no references yet.
- When a canonical name is asked for its reference it creates one if it
doesn't yet have one.
- When loading, for instance, a library, it asks for the reference.
When unbinding a canonical name:
- It removes itself (the canonical name) from the reference
- It removes the reference in itself
- Note: Whatever has a pointer to the reference keeps it, and the
reference points to whatever node it already pointed to.
This also means, that if we have a dill file that's split in two and:
- Load #1
- Load #2
that works fine, but if we
- Load #1
- Unbind canonical names
- Binds canonical names
- Load #2
stuff is not bound correctly (and an error is thrown).
And - the cause of this bug:
- Load #1
- Load #2
everything is fine
- Unbind canonical names
- Binds canonical names
- Load #2'
stuff is not bound correctly --- references points to stuff loaded as #2,
not as #2'. On top of being weird, wrong and confusing it also caused wrong
things to be but into the class hierarchy which ultimatly caused the crash.
This CL fixes it by not calling unbind and force loading of dill files
(at specific call sites) to create new libraries
(and in the process overwriting references ".node").
Revert "[dartdevc] Retry ddc incremental compile on crash"
This reverts commit ecdbdf00b8.
Revert "[kernel_worker] retry on failure"
This reverts commit 43eebea5a3.
Fixes#36644
Bug: #36644
Change-Id: Id8f548179e6a409b01f2ebfa3219f94cb64b1c05
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/100380
Reviewed-by: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Vijay Menon <vsm@google.com>
Reviewed-by: Jake Macdonald <jakemac@google.com>
Reviewed-by: Jenny Messerly <jmesserly@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
It's simply an alias for `dartdevc --kernel`, and now that build_runner
is switching to that, there's no reason to keep it around anymore.
Change-Id: I43d30a582314a236bcfa2e3a0b50bb48ddac79f8
Reviewed-on: https://dart-review.googlesource.com/c/88281
Auto-Submit: Jenny Messerly <jmesserly@google.com>
Commit-Queue: Vijay Menon <vsm@google.com>
Reviewed-by: Vijay Menon <vsm@google.com>
The new file pkg/dev_compiler/lib/src/analyzer/driver.dart handles
building the linked summary for a build unit, and then is capable of
doing analysis using LibraryAnalyzer.
The algorithm is very similar to analyzer_cli's build mode. The
biggest difference is that `dartdevc` has existing support for
discovering source files from the explicit source list (rather than
requiring every source to be listed on the command line). We don't want
to break that support, so there's a bit of logic to follow imports,
exports, and parts.
After the linked summary is produced, DDC gets the analysis results
(errors and resolved AST) for each library, and compiles it into a JS
module.
Change-Id: I7bf1ce1eca73fd036002e498de5924c488b534dc
Reviewed-on: https://dart-review.googlesource.com/c/82469
Commit-Queue: Jenny Messerly <jmesserly@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Vijay Menon <vsm@google.com>
`dartdevc --kernel` is now equivalent to the old `dartdevk` command.
This will make migration easier, as it's now just a flag to enable
CFE/Kernel. `dartdevk` is now deprecated, but it can be supported for
a while as it just calls `dartdevc --kernel`.
Change-Id: Ib8d09f74556740a3af11c753f80cd87bd4a09044
Reviewed-on: https://dart-review.googlesource.com/76566
Reviewed-by: Vijay Menon <vsm@google.com>
Commit-Queue: Jenny Messerly <jmesserly@google.com>
This uses optional new/const and `=` in named argument defaults.
All changes are automated, except for:
- utils/dartdevc/BUILD.gn: run DDC build scripts with --preview-dart-2
- pkg/dev_compiler/tool/patch_sdk.dart: add a TODO that Analyzer doesn't
supporting implicit const in libraries.dart
- pkg/dev_compiler/tool/input_sdk/libraries.dart: was not formatted due
to the aforementioned Analyzer bug
- tools/bots/test_matrix.json: run DDC sourcemap suite in Dart 2 mode
- pkg/pkg.status: skip pkg/dev_compiler if running in Dart 1 mode
Change-Id: I9b80ccba0c2cc7b66efc662a0b16562e3660aee3
Reviewed-on: https://dart-review.googlesource.com/60402
Commit-Queue: Jenny Messerly <jmesserly@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
This works around broken FunctionTypeImpl.== in Analyzer. Also
makes DDK's type naming heuristic more consistent with DDC.
Change-Id: I09527fad681c3fdc6c66654e572e9b03c57491bd
Reviewed-on: https://dart-review.googlesource.com/37120
Reviewed-by: Vijay Menon <vsm@google.com>
Commit-Queue: Jenny Messerly <jmesserly@google.com>
This ports a fairly large part of DDC's Analyzer-based code generator,
however most nodes are not supported yet.
The goal is to preserve all functionality of code that was ported,
except for deprecated features (e.g. mirrors, fuzzy arrows, libraryRoot).
Change-Id: I3b10d5773c7c10a740fa336720243b03c6b82529
Reviewed-on: https://dart-review.googlesource.com/10705
Reviewed-by: Vijay Menon <vsm@google.com>
Highlights
* compile one module at a time
* use summaries to speed up compiles
* use command runner so we can add more commands later
* some long needed renames and file organization
* various other technical debt has been addressed
Lowlights
* lost node.js runner/tests (node output format still supported)
* possibly lost some closure support/workarounds (format still supported)
* needs more end-to-end tests of the new system
R=vsm@google.com
Review URL: https://codereview.chromium.org/1879373004 .
This change removes functionality that is not part of the core Dart Dev
Compiler, in particular those features that were not designed for
incremental/modular compilation.
For a while, the primary way to use DDC will be as a compiler invoked by
a build system, e.g. make or bazel or some node.js based-build system.
We'd love to see the user functionality provided by these return.
In particular, a well designed server+watcher system would be a huge
boost to productivity!
I'll see about moving over HTML reporting to Analyzer CLI. It has a lovely UI.
Thanks to everyone who contributed these features.
The following features were removed:
* DDC transformer. Transformers require whole world, in memory files.
* DDC server. The server has its own mini-build system.
* Various kinds of reporting. These should be moved to Analyzer CLI.
Note: batch compiler and the node runner are left for now.
R=vsm@google.com
Review URL: https://codereview.chromium.org/1788973002 .
Devon Carew