Preparation to begin migrating dev_compiler libraries to null safety.
With this change any file we remove the old language version comment
from will be opted into null safety.
Change-Id: I567d139a6c6bfa0b8f820b16e3eb87a2f49228b3
Issue: https://github.com/dart-lang/sdk/issues/46617
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/206961
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Recent flakes in webdev CI show failures to load dill files
due to broken sockets (most likely caused by connection timeouts).
This change adds retries and timeouts to the asset server file
system to make it tolerant to breaking connections.
- Add RetryTimeoutClient wrapper for HttpClient that performs
retries with delays and connection/response timeouts, based
on the idea in
https://github.com/dart-lang/http/blob/master/lib/retry.dart
- Make AssetFileSystem use the RetryTimeoutClient.
- Add tests for reading multiple files concurrently.
- Add tests for ExpressionCompilerWorker reading assets using
standard, multiroot, and asset file systems.
- Simplify uri that AssetFileSystem uses to query the asset
server, since we no longer need to load package uris.
This will eliminate a step in uri translation in dwds.
- Validated that changes do not break google3 manually.
Change-Id: I2ff163b8d99cd0b7551f3f33a71e6b306540e3c9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/204880
Commit-Queue: Anna Gringauze <annagrin@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
We are seeing CI flakes in webdev when using expression_compiler_worker
in tests involving expression evaluation, for example, see linux tests
for dwds in the following PR:
https://github.com/dart-lang/webdev/pull/1343
The logs show that HttpFileSystemEntity.exists fails due to a broken
pipe, which we suspect is due to http client closed too early.
This change is an attempt to fix the problem by
- logging exceptions thrown in expression compiler worker
- awaiting for the request to be read before closing http client in
HttpFileSystemEntity.
TEST=pkg/dev_compiler/test/expression_compiler/asset_file_system_test.dart
See investigation of the CI issue in:
https://github.com/dart-lang/webdev/issues/1345
Closes: https://github.com/dart-lang/sdk/issues/46388
Change-Id: Iaf98f08e8ebb618bf8365bd497f01ae685f0d3f2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/203841
Commit-Queue: Anna Gringauze <annagrin@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Apply new lints, cleanup violations, and ignore in `lib/src/js_ast` to
avoid adding additional diffs with the version it was forked from.
Change-Id: I1def25865bf195120c594223ebdc0f59139e75b7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/192241
Reviewed-by: Mark Zhou <markzipan@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
This is part of a series of changes to add support for SDK expression eval tests.
Change-Id: Ia96931fdf81324fa131014b49ec2067507c451f2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/191022
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Anna Gringauze <annagrin@google.com>
Commit-Queue: Mark Zhou <markzipan@google.com>
The full workflow for an end-to-end test:
1) Perform test/compiler options pre-initialization.
2) Start an instance of Chrome (with 1 tab) and save a persisted debug connection for use in all tests.
3) For each separate Dart program to be tested:
1) Create inside a temp directory the HTML bootstrapper, DDC-compiled JS sources, and auxiliary JS files (dart_library.js or require.js).
2) Initialize a DDC ProgramCompiler/IncrementalCompiler and perform a full compile of the program, saving the compiler's state for subsequent incremental compiles.
3) Enable the debugger and set a URL breakpoint at the program's main JS entrypoint.
4) For each test for this Dart program:
1) Navigate to the HTML bootstrapper, pausing when the target module is loaded (at the breakpoint set above).
2) Set a breakpoint at a JS location translated from a Dart breakpoint ID via source maps.
3) Resume the debugger, pausing at that breakpoint. Remove the breakpoint.
4) Reconstruct the local JS scope, then evaluate the Dart expression.
5) Evaluate the JS expression inline, then compare results with expectations.
5) Disable the debugger to clear its state.
4) Shut down Chrome and clean up any temporary directories.
Other notes:
* Supports bootstrapping/compilation on AMD and DDC module systems only (though expression eval is only supported on AMD)
* Requires that Dart breakpoint IDs be set declaratively (no support for columns)
The test structure/flow is subject to change. While I port existing tests, Dart programs will consist of inline source file strings with simple breakpoints. In the future, we want to allow more complicated Dart programs to be specified (like in the modular test framework) and more complicated expression evaluation test patterns (rather than allowing only a single evaluation per test).
Change-Id: I5de7cfa66991fd14b24fa16edd1615f55c041ae3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/190962
Commit-Queue: Mark Zhou <markzipan@google.com>
Reviewed-by: Anna Gringauze <annagrin@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>
Only ~29/100 calls for runtimeCall and ~2/31 calls for runtimeStatement
were using the single value option. Change to take a `List<Object>`
always and add list literals to those calls which were previously only
passing one value.
Update pubspec SDk constraint so that the analyzer will allow the `..?`
syntax.
Change-Id: Ib8eb8eb854a8aa04e36dc5cc713016a43b8e9325
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/103361
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Nate Bosch <nbosch@google.com>
Useful for tracking pkg usage across the SDK
Change-Id: I16fe0e62922afd76270b03e9423632cd900d4c61
Reviewed-on: https://dart-review.googlesource.com/c/91844
Auto-Submit: Kevin Moore <kevmoo@google.com>
Commit-Queue: Jenny Messerly <jmesserly@google.com>
Reviewed-by: Jenny Messerly <jmesserly@google.com>
The generated summary file matches the generated DDC sdk - i.e., it
does not include dart:io. I modified the codegen_tests to the summary
and had to prune the parts of unittest that relied on dart:io.
Paul / Konstantin: can one of you please look at the summary part?
Bob: can you please look at the unittest changes?
R=rnystrom@google.com, scheglov@google.com
Review URL: https://codereview.chromium.org/1982853002 .
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 .
fixes https://github.com/dart-lang/dev_compiler/issues/471
Changes here are:
* Analyzer now infers list/map literals
* Analyzer changed how isPotentiallyMutated* APIs work, so we need to track current function
* Another fix to arrow functions. We shouldn't skip generating covariant arg checks. If there were any, we use `=> { block }` form rather than `=> expr` form.
R=vsm@google.com
Review URL: https://codereview.chromium.org/1757343002 .
Some of the high level changes are:
* visit catch body, fixes#463
* handle temps created by the compiler. These were in some cases treated incorrectly as non-null (see tests diff)
* compute nullable in the same pass as visiting assignments
* simplify visiting += and ++, fix ++ (it was dead code, #463)
* simplify _isNullable
* if we fail to see a variable declaration, treat it as nullable
* stack trace in catch is treated as non-null
R=vsm@google.com
Review URL: https://codereview.chromium.org/1751963002 .
