We are establishing a convention that nullability wrappers will be emitted at the
call sites of 'is', 'as', and '_check' calls (when necessary). Additional wrappers
will be emitted when forward-declaring generic types at the top level - but only
around the generic parameters themselves.
For example, declaring List<int>, List<int?>, List<int>?, and List<int?>? results
in two top-level classes: ListOfInt(int) and ListOfInt$(dart.nullable(int)).
Change-Id: I2d91e170d8e1e911ad9eb70d6b4d67f1cc4cdbc1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/129921
Commit-Queue: Mark Zhou <markzipan@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
This change does not enable the lint yet because there are many more violations
in the test and tool directories. I'm going to clean those up in a separate
change.
Change-Id: I8a7f9a9004d329db5ba34030cc8aa8e20d07f3ec
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/130012
Reviewed-by: Nate Bosch <nbosch@google.com>
Commit-Queue: Nate Bosch <nbosch@google.com>
Fixes#39074
DDC emits Dart code that can usually be called with the same semantics
as JS there is no guarantee that a function passed to JS and then
invoked successfully was wrapped with `allowInterop`. The wrapping is
always required in Dart2JS. To make DDC more strict, add interceptors
that check for the usage of `allowInterop`.
Whenever a JS interop function or setter is passed an argument which is
statically typed as a Function, but not wrapped with `allowInterop` at
the call site, wrap it with `assertInterop` which will check the
argument at call time and fail with a clear error if it was not wrapped.
Whenever a JS interop function is torn off, either at the top level or
from an instance, wrap it with a function that will also inject these
checks at runtime.
There are still holes where we can't catch the mistake:
- An argument which is statically dynamic and a Function at runtime
won't be caught.
- A Function which is stored in a collection won't be caught.
- A JS interop definition where a getter returns a Function which takes
a Function as an argument is not checked.
- A dynamic call through to javascript is not checked.
Changes:
- Refactor `_isJsLibrary` and add `isJsMember`, and `isAllowInterop`
utilities to determine what needs wrapping.
- Update `assertInterop` to give a more clear error when it fails, and
to ignore non function arguments.
- Add `tearoffInterop` to wrap a function an ensure that any function
typed arguments are wrapped.
- Inject `assertInterop` around Function arguments passed to JS methods.
- Inject `assertInterop` around Function arguments passed to static or
instance JS setters.
- Inject a runtime wrapper around static or instance Function tearoffs.
- Add a test covering all flavors of checks that are supported.
- Change the interop expando to an `Expando<dynamic>` in the NNBD SDK to work
around a stricter type check. https://github.com/dart-lang/sdk/issues/39971
Potential improvements:
If the `tearoffInterop` turns out to be too heavy, we could loosen it so
that we only wrap methods if any of their argument types are statically
declared to be a Function.
Change-Id: Ibc92df5b54e1a041b4102a07b8398b774b6bd1d2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/128462
Commit-Queue: Nate Bosch <nbosch@google.com>
Reviewed-by: Vijay Menon <vsm@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
This code is causing an issue when running tests with the NNBD SDK. As I
understand it used to be possible to pass a function to assert but that feature
was removed from the language. We might as well remove it from DDC too :)
Change-Id: Ia62c653ec9d4c98694986b2c326d2b1b027b9ed9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/128308
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Mark Zhou <markzipan@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
This change fixes the issues causing build failures when using the
forked NNBD SDK sources and trying to build the dartdevc_kernel_sdk
target.
The end result is a dart_sdk.js file that is known to be incorrect
(missing uses of the legacy and nullable type wrapping) but serves
as a baseline for improvement. Some tests of the runtime directly
will correctly pass.
Following changes will turn on the type wrapping and we can start
diagnosing and fixing the issues that appear.
Fixes: #38665
Change-Id: Iddcf31ef2520fa54bf7d9ae6262c2264636b9b10
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/127780
Reviewed-by: Mark Zhou <markzipan@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
We are temporarily building a smaller SDK platform to make progress building
applications against the forked sdk_nnbd sources. This is because some of the
libraries have not yet been ported and they don't compose well.
I needed to thread the status of the non-nullable experiment through the front
end entry point and into the target options, and native types.
Also includes some standardization of the flag name in DDC.
https://github.com/dart-lang/sdk/issues/39698
Change-Id: I4bdd503be694b28d7f95828d4af28d1d5fb3691f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/127486
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This is the first step in deleting legacy DDC!
* Default all invocations of DDC to run the kernel version.
* Disable all tests that run analyzer DDC.
* Detect the most likely case when invoked with an analyzer
summary and print instruction to update build_web_compilers
dependency.
I will follow up with deletions, and a rename of the test configurations/
builders to reclaim the names (ddc vs ddk, dartdevc vs dartdevk).
Issue #38777
Change-Id: I1477f0274b6b7f345a5e19d2b3f93797c454a09e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/127067
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Mark Zhou <markzipan@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Use ES6 destructuring to handle optional positional arguments more compactly.
Note, this doesn't actually change calling convention in DDC, just how
optionals are handled at the callee.
Given Dart:
void foo(arg1, arg2, [opt1, opt2 = def2]) {
...
}
old JS:
function foo(arg1, arg2, opt1, opt2) {
if (opt1 === void 0) opt1 = null;
if (opt2 === void 0) opt2 = 42;
...
}
new JS:
function foo(arg1, arg2, opt1 = null, opt2 = def2) {
...
}
We should be able to similar with named params.
Change-Id: I8491a4517d729ab1dec40c1ed2073b9c33cdffe0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/124107
Reviewed-by: Mark Zhou <markzipan@google.com>
Commit-Queue: Vijay Menon <vsm@google.com>
Original change was broken by the fact that DDC expects all types marked as
native have all their superclasses marked as native when the super classes are
compiled.
In this case `MapMixin` from dart:collection was not being marked as native and
the only reason it was working before was that the library dependency enforced
the necessary order.
* Now `MapMixin` is explicitly marked as native.
* Added a test case to use some of the API on `window.localStorage` that is
inherited from the MapMixin class.
Change-Id: I1584bfb86179016ee12c2acc5cfbbe81d086841e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/126906
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Mark Zhou <markzipan@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Replace it with TypeSystem from lib/dart/element/type_system.dart,
or (internally) with TypeSystemImpl.
We keep the old TypeSystem where its is exposed from API:
- ResolveResult.typeSystem
- AnalysisSession.typeSystem
- AnalysisContext.typeSystem
We will make changes to these as a breaking change later.
Change-Id: I40ca53ea77e440457c6d0f3832ec3b6286bacdf0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/125770
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
This is to align how we pipeline each step in the build with other tools. It
will also help with caching and incremental rebuilds when doing local development
in ddc.
Change-Id: I8ff9988927d5632301926fca173c01dd281f923f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/125447
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Vijay Menon <vsm@google.com>
The goal of this change is to make it possible to start iterating on nnbd tests
for DDC. This keeps the current philosophy of keeping NNBD and non-NNBD build
configurations separate, except that NNBD builds are allowed to consume library
sources from the non-nnbd sdk.
This change addresses the first set of errors that are encountered when trying
to build a fully NNBD configuration:
* CFE has issues with type promotion, for that reason we remove
`--enable-experiment=non-nullable` in vm build rules, and we use a smaller
training data when creating the dartdevc app-jit snapshot.
* We'd hit compile-time errors with nnbd libraries with inconsistent
patchfiles. To avoid that, the libarries.json points to the non-nnbd SDK
sources for most dart:* libraries.
Change-Id: Ie6226b3bd8a92b4a1632dd84a5db2f04238fd4f8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/125080
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Change Expression.getStaticType to take a StaticTypeContext instead
of a TypeEnvironment.
The StaticTypeContext provides access to the TypeEnvironment and the
current 'this type' as well as determining the nullability state of the
enclosing library.
This change is needed to support nnbd types for getStaticType and also
serves as a step towards supporting caching during static type
computations to avoid repeated computations of the same (complex)
expressions.
Change-Id: Ied974dff7f6f7c3c8f262aa80c8dea5c674662f7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/124683
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
* Treat the assertion condition offset as a character offset in the file.
* Allow unrecognized characters to be replaced by a placeholder character. This
is unrelated to the fix but is just a precautionary measure.
Fixed: 39271
Change-Id: I4871ea41d3a46d26ecac5047265a1dbc1c889350
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/124602
Reviewed-by: Vijay Menon <vsm@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
This unblocks changing this logic for NNBD since they are now forked.
The custom logic for FutureOr has been problematic to represent in the patch
files. They need to be callable from the class but they can't be static methods
in Dart because they reference the generic type argument. It is a design quirk
of the runtime representation that the type argument is captured in the wrapping
closure and in scope that allows the existing implementation to work.
In a future change I will thread an NNBD flag through the compiler to emit
different logic for the FutureOr type tests when running with NNBD.
Change-Id: I9463e3cd375f8098592ea84e956e833952f41bb3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/123921
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Jens Johansen