Null-out DeferredLoadTask.importSets to free up all the ImportSets.
DeferredLoadTask
-> ImportSetLattice
-> ImportSet({})
-> all other ImportSets via transitions.
Change-Id: I552b4a37396277b9a43a6a823622ec2d7a542848
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/148226
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Stephen Adams <sra@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>
- Fix unwrapException to ensure it never returns null.
- Wrap `null` (from JavaScript) if necessary.
- Move `saveStackTrace` to top-level function to avoid closure allocation
- Force inferrer type for unwrapException to non-null to avoid tests
at 'on Object' clauses.
Change-Id: I6e2ae2722420f14f73e75c2f3d4bdb56544db66e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/147841
Reviewed-by: Mayank Patke <fishythefish@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
Supercedes previous work here: https://dart-review.googlesource.com/c/sdk/+/128849
Change overview:
* In legacy mode, the isRequired flag for parameters in the kernel IR is treated as false (though this bool is still processed during serialization).
* Adds a Set<String> to the element model to represent required-ness. All named parameters are still stored in a single "bag".
* ParameterStructure objects additionally emit/ingest all required named parameters as well during serialization.
* A bool indicating whether or not a parameter is required is emitted after each named parameter when serializing FunctionTypes.
* JS identifiers for functions with required named parameters now emit '$req' before each required named parameter. E.g., dynamic_Function_String_$named_p0_int_$req_p1_int for dynamic Function({int p0, required int p1}).
* Recipes now indicate required named parameters with '!' instead of ':'. E.g., @(int,{p0:int,p1!int}) if p1 is required and p0 is optional.
* A requiredNamedSeparator was added to the shared recipes to accommodate the above.
* The RTI now represents named function parameters as a repeating list of triplets (name/bool/type). This adds a bit of overhead to our parser but makes subtype checks simpler.
* Does NOT include changes to Function.apply + auxiliary information attached to closures. These will be added in a later patch.
Fixes#39730
Change-Id: I9c9eaac28da0d63bb16bdb439f021f1470539563
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/141204
Commit-Queue: Mark Zhou <markzipan@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
We were only treating Object as a top type if NNBD was disabled. This is
incorrect and we should be treating Object as a top type whenever legacy
subtyping is in effect. In particular, Object acts as a top type in weak
mode.
Change-Id: I76acc25e92fda2b9e2b7872fc72d319161318874
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/144689
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Mayank Patke <fishythefish@google.com>
Previously, we said that the LUB of instantiated subtypes/subclasses for
a JS interop class was JavaScriptObject. This worked in most cases, but
failed when JavaScriptObject was not marked instantiated.
One way this could arise is if the only calls to JS_INTERCEPTOR_CONSTANT
were JS_INTERCEPTOR_CONSTANT(Interceptor). The LUB has to be some
interceptor, but JavaScriptObject (and its interceptor subclasses -
PlainJavaScriptObject, UnknownJavaScriptObject, and JavaScriptFunction)
are not instantiated, so we actually need to go even higher in the type
lattice.
In fact, the class hierarchy already knows how to do this - we need to
assist it a little in going from a JS interop class to JavaScriptObject,
but it can recursively compute LUB(JavaScriptObject) just fine.
Change-Id: I1e08faa42c42a43afc0b1cfafb5a012f5cd69193
Bug: https://github.com/dart-lang/sdk/issues/41330
Fixes: https://github.com/dart-lang/sdk/issues/41330
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/144667
Reviewed-by: Mayank Patke <fishythefish@google.com>
Commit-Queue: Mayank Patke <fishythefish@google.com>
Ensure that a generator entry point only passes type arguments for
parameters that are not erased.
The generator header was passing too many arguments to the generator
body, causing the element type to be misaligned.
Change-Id: I062df5f7172ed8bb410c81013a3faee35d66ef1b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/144351
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
The dart2js option --dump-ssa=pattern outputs the SSA CFGs for methods
with names matching the RegExp 'pattern' to a '.cfg' file alongside
the javascript output, e.g. 'main.js.cfg'.
To dump all CFGs, use --dump-ssa=.
Change-Id: I8227232d9950bf3d30df0c87709b0c24e8944759
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/143082
Commit-Queue: Stephen Adams <sra@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Currently, in order to change experiment flags between tests,
we rebuild the sdk. This is made more complicated by null safety
because now we may want to enable null safety while compiling
the sdk but not while compiling user code.
To simplify things, this cl changes dart2js to always use the
prebuilt sdk, and to assume that no experiment flags require
rebuilding the sdk.
Change-Id: Ia1bbdc88d191f1a71d1688685186457fcfba28aa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/142703
Commit-Queue: Joshua Litt <joshualitt@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Derive whether legacy and nullable types are emitted based on the
provided sdk libraries and only enable the non-nullable experiment
when building the platform files.
The test matrix continues to enable the experiment temporarily
because test_runner currently doesn't support running with the
ReleaseX64NNBD configuration if it is not enabled in test.py
Change-Id: I7322906e928c68acab77087bcba76f06ef4bf983
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/141850
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
- '_as' is now specialized on first use, like '_is'.
- '_is' specialization on `T?` that uses `T._is`
- recognize legacy versions of simple type tests (e.g. is int*)
The T? specialization makes a 2x improvement on some of the ListCopy
benchmarks on 'spec-mode' dart2js because some iterators have a T?
check.
Change-Id: I434a43de9e1322b34c3a5e11199415a75b7ed2c7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/140944
Commit-Queue: Stephen Adams <sra@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
Breaking change 40678 requires the constructors int.fromEnvironment and
String.fromEnvironment to get new default values for the named
parameter `defaultValue`. This CL changes usages of these constructors
such that they do not depend on the default value, such that it
becomes a non-breaking change for code in the SDK repo to perform the
change in sdk and in sdk_nnbd.
Change-Id: I82af0e1f92d6cd3618b65c0c50d754ae8c39eb0a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/140284
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
A NullableType can be a precise AbstactValue if the base type can be
precise.
The main effect is more lowering of field setters to HFieldSet,
(i.e. for fields with nullable types.
Change-Id: If1f92e1a79da87a73df02da3b9fc8fc3542f7b40
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/139326
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
We were accidentally dropping FutureOr on the `FutureOr<NullableR>*?` case. That is we had:
FutureOr<NullableR>*? => NullableR
instead of:
FutureOr<NullableR>*? => FutureOr<NullableR>
Change-Id: Idfe2748ccb03a9d4ee18b57022f9bdb7fbb55d42
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/140243
Reviewed-by: Mayank Patke <fishythefish@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
CastError is deprecated and _TypeError now implements CastError, so
it is possible to remove the distinction in generated code.
All checks now go via Rti._as(x) to some _asXXXX method.
Change-Id: I4ce6735b6c904bcbc366de92ed149716caf9ae81
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/139959
Reviewed-by: Mayank Patke <fishythefish@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
dart2js will migrate slowly to modern JavaScript.
The --legacy-javascript flag causes emitted code to be compatible with
IE11, our only supported non-modern target. This is a temporary flag
until IE11 is removed from support.
The negative flag --no-legacy-javascript allows the code to be
incompatible with legacy browsers and, over time, be improved to take
advantage of modern JavaScript features.
Initially --no-legacy-javascript will use some minimal features that
are incompatible with IE11 as a 'trip-wire' to ensure that
--legacy-javascript is always used for IE11. dart2js analytics can
then be used to assess how much --legacy-javascript is used. (The
'trip-wire' unsupported feature is unguarded use of JavaScript
Symbols.)
The default at this change is --legacy-javascript so that this change
is non-breaking. The default will be changed soon to
--no-legacy-javascript.
Change-Id: Ic13461362a5fa80293fb66b112945d1404a64a03
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/139867
Commit-Queue: Stephen Adams <sra@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Stephen Adams