This adds a new messages kind 'info' to the CFE for showing general
information during compilation. A 'configuration' options is added
to `CompilerOptions` for telling the CFE how it is run.
The configuration 'compile' is added for when the CFE is invoked to
produces an "executable" as when running `dart compile`. When
configuration is set, the CFE emits an info message about the
null safety compilation mode.
Support for `dart compile exe` and `dart compile js` is added in this
CL. Support for `dart compile kernel|app-jit|aot` is not included.
In response to https://github.com/dart-lang/sdk/issues/44234
TEST=pkg/dartdev/test/commands/compile_test.dart
Change-Id: I08f51e2a3f5ad4841c4d703bcd266b7afb63c7c6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/178982
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
This consists of a few combined changes:
* support `@Native` on tests: This entails calling registerExtensions
on user code, but only when running on native tests (which are explicitly
added to an allow list).
* support for invoking external top-level methods also on native tests.
* support for running `applyExtension` later in tests. This is because
tests introduce the JavaScript definitions after the calls to
registerExtensions happen. Note: this wouldn't be necessary if we one
day change how tests are loaded (e.g. if we can load the JavaScript
portion of the test before the module compiled by dartdevc is loaded).
That would entail more infrastructure work and given that this is only
used for ~200 tests, it doesn't seem worthwhile at this time.
* ensure extension symbols are also stored in `dartx.*` from a native
test. This is to ensure dynamic calls are fully supported.
* changes to the dart2js runtime to ensure the test code can run in both
dartdevc and dart2js with the same API.
* one updated test: all native tests need to be updated and I'll follow
up with those, but the changes on this test are included in this CL to
illustrate how this all fits together.
After this change (and parent changes), you can now run:
./tools/test.py -m release -c dartdevk -r d8 dart2js/native/native_checked_arguments1_frog_test
Change-Id: I4c2615a80b0e7611aa6f57abaa55b4e03b42bfe4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/177180
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Reviewed-by: Mark Zhou <markzipan@google.com>
Bug: https://github.com/flutter/flutter/issues/73176
This reverts commit 825f56c6aa.
Both ddc and dart2js keep a set of native class names to make sure
@JS() classes don't conflict. Instead of processing native classes
for every component, this CL caches the set of native classes. This
should address the recompile time issues related to the original
revert.
Change-Id: If8028f0842440e8b9354bec9d7f72d0d42fcd8bd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/178926
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
commands
- Added support for --define to the VM and dart2js
- Added support for -D and --define for `dart run` and `dart compile js`
Remaining improvements:
- Add support for providing multiple comma separated values for `dart
run`, `dart`, and `dart2js`
Related issue: https://github.com/dart-lang/sdk/issues/44562
TEST=Updated CLI tests and added new dart2js tests.
Change-Id: I9379c7aee1eab377adb3438393d9ad79c4938cc4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/178262
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
This change does a small fix to exclude line numbers from the golden
files produced by check_nnbd_sdk.dart. Doing so helps keep the golden
file more stable and less likely to require updates when developers make
unrelated changes to the core libraries.
There are very few failures that remain and now that the CFE is more
mature, we may be in a position to stop using the patch-sdk mechanism to
test the validity of the migrated sdk.
Change-Id: Id41448f23871d0a43257db5dbf5b0b062e2eaddd
Bug: https://github.com/dart-lang/sdk/issues/44491https://github.com/dart-lang/sdk/issues/44618
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/178726
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
LiteralExpression used to be the mechanism for 'interpolating' the
`JS` pseudo-function, but that long ago was reimplemented via the
js_ast template feature.
There are a few vestigial uses of LiteralExpression, but as none of
them use the `inputs`, this field is removed.
Change-Id: I4cd7c64766a7d6d9dd2c196c134bbfcb536fd2f4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/178400
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
During expression evaluation, we are collecting all variables in
all scopes that contain the current breakpoint line, and adding them
as available in current scope, which makes variables declared below
the current breakpoint line declared but undefined in JavaScript.
There is one exception to this seen so far - a variable
declared on the current breakpoint line might appear as not declared
in JavaScript and cause expression evaluation not to work due to
JS compilation errors.
This change fixes the issue by not collecting variables that are
declared on or after the current breakpoint line, making them undeclared
in dart (which also is correct according to dart scoping rules).
Closes: https://github.com/flutter/flutter/issues/72094
Change-Id: I113b69531171e0348d44edb8db6dd08a599c9db3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/177760
Commit-Queue: Anna Gringauze <annagrin@google.com>
Reviewed-by: Mark Zhou <markzipan@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
This change makes dart_library.js more resilient so it can run in a
browser or in d8.
This is a necessary step to later enable test.py dartdevk tests in d8.
Change-Id: Ic8e5bbc9f1bbc6707a876208605f4fcaad41cee7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/177000
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Mark Zhou <markzipan@google.com>
This CL adds stub for each concrete mixed in member into mixin
applications. The body of the stub calls the original member via
a super call.
This addition means that resolution of super access now use the
stub and not the original declaration as the target, which means
that it will be correct even when mixed in members are cloned. For
this reason, dart2js no longer needs to perform its own super
member resolution.
When a super call targets a mixin super stub (after cloning) it
can be optimized away by redirecting the call to the `stubTarget`
of the call. This optimization is performed in dart2js.
Since dart2js now uses the correct super target, its runtime
mixin application needs to avoid overriding members already
declared in the mixin application. These members are the
forwarding super stubs which ensure that correct runtime types
when members with covariant parameters are implemented.
Change-Id: Iab71ffcc400aa6a683987bc20b9553a263ebc8e1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/176526
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Hopefully this will avoid bugs in the future if the lowering of
late variables changes.
This does not change the current optimization for late variables
with list literal initializers. That lowering introduces a final
variable that is not marked as late that appears as the receiver
in this logic.
Change-Id: Ib99d0987b166d3f38b60d0dce3fedb166d772e64
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/175444
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Before Null Safety, `_EventStreamSubscription.cancel()` used a trick
to run with synchronous timing even though it was typed to return a
`Future`. During the migration of the SDK to support Null Safety it
kept the synchronous timing in weak mode, but was changed to
asynchronous in sound mode so that the behavior matched the method
signature. In hindsight, changing the timing when opting into Null
Safety is problematic:
* A shared package has no control over what mode it runs in. Libraries
may be opted in and run their tests with sound null safety but the
apps they are used in could still be running in weak mode. This
results in library unit tests that behave differently than the
production app that deploys the code.
* This codepath can be triggered by EventTarget.dispatchEvent() from
dart:html which should have synchronous timings for the event
listeners before returning to the calling code. The asynchronous
timing when running with sound null safety is inconsistent with the
browser API.
This change reverses that migration decision and keeps the synchronous
timing in both modes. To support this in sound mode it returns a
special future value that is internal to the SDK and known to be used
for synchronous timing.
This change also removes the workaround introduced in DDC to avoid
warning/failing when `_EventStreamSubscription.cancel()` returned
null and the extra warnings/errors features were enabled in weak
null safety mode.
Change-Id: I6b08a2ada5b10120bea787ad59d1d58e6e181de5
Fixes: https://github.com/dart-lang/sdk/issues/44157
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/175323
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Emphasize that the operation is going away,
and mark constructor as deprecated.
TEST= Refactoring+deprecation only, covered by existing tests.
Change-Id: I82aa044cd2cf7bf347b624371399f44bda8f4a07
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/173261
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
This change selectively containerizes many top-level JS constructs. Containers maintain a max size of 500 elements for JS optimization purposes. Containers with unspecified key names are emitted as JS arrays. Containerization occurs for symbols when the number of top level symbols exceeds 600 but is automatic for other constructs. However, containerization in the Dart SDK only happens for web libraries for runtime optimization purposes.
Two types of common DDC constructs result in their capture by all subsequent closures:
* Self-referential variables:
var selfLambda = () => selfLambda = "foo";
* Variables referenced in sister functions:
var unused = "foo";
function unusedF() => console.log(unused);
The following are now accessed through an additional level of indirection:
* Type generators (frequently follow the self-referential variable pattern)
* Constant cache variables
* Dart private names (used for virtual method dispatch)
* Top-level string constants (such as URI strings)
Additional changes:
* The ModuleItemContainer handles automatic renaming of arbitrary top-level JS expressions. This is a multimap that maps keys of an arbitrary type to JS key-value pairs.
* The CacheTable and TypeTable have been unified. The old cache table seemed to have been created with a similar use case as the ModuleItemContainer but had become too specialized.
* The new TypeTable unifies much of the logic for emitting types, including explicitly separating the discharge of types dependent on free variables (such as generic types, generic functions, and their bounds) from types that are fully bound.
Reduces top-level captured variables in the SDK by ~5711 per recursive callback.
Change-Id: Id44efef8e93d1a83fdac808814d9ace99c4d27bd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/173800
Commit-Queue: Mark Zhou <markzipan@google.com>
Reviewed-by: Anna Gringauze <annagrin@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
This is in preparation to migrate package:kernel to null safety.
For the visitor interfaces to support non-nullable return types, the
implementations must avoid using `null` as return value in its base case.
TEST=Refactoring
Change-Id: I9f9b318982148d844be9826a5f8c88374a9fc402
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/172180
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Adds a @pragma("vm:recognized", <kind>) to all recognized methods, where
<kind> is one of "intrinsic", "graph" or "other", corresponding to the
kind of recognized method.
When running in debug mode, it is checked that all recognized methods
are marked with the correct kind of pragma, and that all methods marked
with the pragma are in fact recognized.
This enables kernel-level analyses and optimizations to query whether
a method is recognized by the VM.
TEST=Asserts that check the correspondence both ways, covered by test
suite, in particular the various CompileAll tests that compile all code.
Change-Id: I12f3305c72a93ecb1aefae2d66e3d9a7dae23b44
Cq-Do-Not-Cancel-Tryjobs: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/168951
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
- Define private symbols load without reloading the module
and knowing module format
- Remove libraryName->moduleName map from ExpressionCompiler's
compileExpressionToJs API as a result of above
- Make ddc tolerate null locations on kernel loaded from dill
during assert insertions for nullability
- Disable asserts in expression compilation worker
due to ddc reading source for assert statement compilation
- Remove unused test configuration for expression compiler worker
- Add and update expression compiler tests
Part of: https://github.com/dart-lang/webdev/issues/1174
Change-Id: Idf8f508308915a5487fa0e9810b5674140393fed
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/170028
Commit-Queue: Anna Gringauze <annagrin@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Simple calls to `List.generate` are expanded into a list allocation
and a loop. This generates better code for several reasons:
- There is no overhead for the function argument (closure allocation,
closure type, closure class)
- Global type inference is more precise since each List.generate list
is tracked separately, and the assignments in the loop give better
inference to the collection's element type.
To get precise element type inference, there are two new JSArray
constructors. Global type inference starts with the element type being
bottom for these elements, avoiding spurious nulls in the inferred
type.
Change-Id: I5efb90651ae3f9eb2e81af556704960cdf0b75c5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/168770
Commit-Queue: Stephen Adams <sra@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Mark Zhou