This reverts commit c81711bdda.
Reason for revert: `Internal Error: Runtime type information not available for type_variable_local` - b/295131730
Original change's description:
> [dart2js] Add runtime type check for `await`.
>
> See https://github.com/dart-lang/sdk/issues/49396 for details.
>
> Fixes: #50601
> Change-Id: Ie89130cffe642b3e4935d7d02fe2e34f7fc8b12e
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/316320
> Commit-Queue: Mayank Patke <fishythefish@google.com>
> Reviewed-by: Stephen Adams <sra@google.com>
Change-Id: I481b119b6569d1bc9cf2ab80d997a3eb6d06f674
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/319421
Reviewed-by: Alexander Thomas <athom@google.com>
Auto-Submit: Oleh Prypin <oprypin@google.com>
Commit-Queue: Oleh Prypin <oprypin@google.com>
Several changes are made:
- createDartExport now does not export methods that define type parameters.
- createStaticInteropMock adds conformance checks to make sure implementing
members can handle all possible values of a type parameter in an interop
member. An error is added to reduce confusion around this.
- Export creator now uses dart:js_interop_unsafe for a lot of its lowering
as the dart:js_util equivalents are buggy when it comes to calling exported
functions in JS with JS types.
- Small code changes are added to backends to handle the above changes.
Change-Id: Ie3b6b157930537267f270b60373b2b17e0a14344
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/316141
Reviewed-by: Joshua Litt <joshualitt@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
There are two changes here that account for ~5% of the cycles spent compiling large programs:
1) Calls to 'runtimeType' (specifically _AbstractType.toString) are expensive and CodegenPhase.name calls this 2/3 times per member in the target program.
2) ModularNamer._jsVariableReservedCache is a late final field that gets instantiated for every namer in the program, of which there is one per member in the target program. All the subsets are static and so _jsVariableReservedCache can be static as well. Ideally this would be const but const sets cannot have duplicate strings and the various subsets have some overlaps.
Change-Id: Iefc294145feebe397b2db84a5f49906c6b1372a1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/317981
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
This renames InlineClass to ExtensionTypeDeclaration, and InlineType
to ExtensionType. Members of extension type declarations are called
extension type members instead of extension type declaration members
for "brevity".
TEST=existing
Change-Id: I91ed62533ddd345644492f04dc3310d007460288
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/316780
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
This removes ExtensionType, ExtensionTypeShowHideClause and
CallSiteAccessKind from package:kernel which where only used by the now
removed 'extension-types' experiment.
A follow-up CL will rename InlineClass/InlineType to
ExtensionTypeDeclaration/ExtensionType to match the names of the
Extension Type feature currently being implemented.
TEST=existing
Change-Id: I58d2e8b0a92ac61329ee161cc6884a2c0e6f87ae
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/316420
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
This was landed a while ago as https://dart-review.googlesource.com/c/sdk/+/254600. However, this had to be rolled back because at the time this increased memory usage for the emitter phase. This change prevented GC from cleaning up the byte arrays of the codegen serialized files which resulted in an increased max heap.
However, now that we map (rather than copy) files into memory, there is no overhead to keeping a reference to the codegen serialization files.
Thanks to recent improvements in the efficiency of deferred serialization this change seems to improve max memory usage by up to 1.2GB for the emitter phase. Avoiding caching results also helps in this regard, usage of the results is fairly localized.
Change-Id: I4d401a877cb74cbb36b511eb598a759fe300fd5d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/316180
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
This change doesn't seem to have a significant impact on most compilation results:
- Golem results show no significant difference in microbenchmarks.
- For a medium and large app tested, while we see a small change in the actual inference results, the generated code is identical before/after this change.
- Timing and memory usage on internal compilations seem comparable before/after this change.
Note: This replaces the need for any notion of "invalid" refines so I will clean up that code in a follow up change.
Change-Id: I2a293eacd944fc17ee2dab97d3d947c042b4038f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/313720
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
This new approach uses static tear-offs where possible to avoid allocating a new Closure for each Deferrable.
Note: This doesn't scale to every case but as of today the one case not covered is a singleton and so only 1 closure should be allocated there regardless.
Data from a fairly large app:
Before:
Total => 3.8GB
Closures => 85.6MB
Closure Context => 71.0MB
After:
Total => 3.7GB
Closures => 28.9MB
Closure Context => 49.8MB
Diff:
Closures => 56.7MB
Closure Context => 21.2MB
Change-Id: If233f958df2822708b51c0d14c7439b5d3a5a07b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/313340
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
When tracing closures, we accidentally ignored the fact that returning from a non-async
function allows the value to flow in other ways (e.g. through the completion of a future).
This changes the node tracer to always consider the async marker when looking at values
that flow into 'MemberInformation' information nodes, which are the nodes we use
to represent the returned value of a method.
Fixes#52825
Change-Id: I3322e105dc9612f47a516a17f9465bf1002a9f87
Fixed: 52825
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/312708
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Reviewed-by: Nate Biggs <natebiggs@google.com>
A user found another case where this fails (b/290868787).
In this case a ForwardingTypeMask is delegating the subtyping checks to its `forwardTo` mask which ends up saying the masks are equal even though the wrapper around the forwarded masks means they are not equal.
Change-Id: I015f2faf57557ff4189acb6c7144d09cf1ae6bb6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/313341
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
The issue here was that isInMask does not hold inversely. The key is that we want to verify which refinements to skip, therefore we want to calculate *in*valid refinements. We want to skip refines where the new type is a Union AND the old tpye is a supertype of the new type. after.isInMask(before) gives us that but !before.isInMask(after) does not.
I've renamed isValidRefinement to isInvalidRefinement to more accurately capture this distinction.
Change-Id: I0d99479357a140095a5d0dfb7e2f987556097891
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/312160
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
It's still unclear why this is causing an issue but this will unblock b/285636639 until the underlying cause is found and fixed.
Change-Id: I44db6059a13738d5781c0557810ee53556ecb9c0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/312100
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
- Only include the script tag src if it differs from the previous log entry.
- Use single letters for each event field's key.
- Fix some typos.
- Remove 'uri' from download event as it can be inferred from script tag src and part file name.
Change-Id: Ib7916ea5e92720a10c7e1e1cab2e535fae2bbf49
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/311180
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
The following would fail unminified because the variable shadowed the
global JavaScript constructor. The fix is to add more global names to
the avoid-list. This is not a problem for js-interop since those are
accessed via `self` or `globalThis`.
```
import 'dart:typed_data';
foo(int Float32Array) => Float32List(Float32Array);
main() => print((foo)(10));
```
Change-Id: I887ece4a888fdab5df437822f9f1f34b384ec24f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/310482
Commit-Queue: Stephen Adams <sra@google.com>
Reviewed-by: Nate Biggs <natebiggs@google.com>
Constant Sets now have their own classes rather than being constructed as a wrapper over a const Map. The new scheme is similar to Maps - using a ConstantStringSet backed by a JavaScript Object 'dictionary' when the elements are all suitable String values, otherwise using a GeneralConstantSet backed by a list of elements that is converted to a lookup map on demand.
Constant Sets and Maps with suitable String keys are backed by a JavaScript Object literal 'dictionary'. The use of the Object literal has been changed so that the property values are no longer the values of the Dart Map, but the position of the key in the order of the entries. The values are provided as a List (Array), so there is an additional indexing operation to access the value on lookup. This does not seem to affect performance.
The advantage of the two-level lookup using the 'dictionary' is that Maps with the same keys (in the same order) can share a 'dictionary'. In order to achieve the advantage, the JavaScript Object is modeled as a first class ConstantValue - JavaScriptObjectConstantValue.
These changes achieve a code size benefit of -0.90% (~130K) on the main unit of a certain large app, and -0.35% for flute/benchmarks/lib/complex.dart
Change-Id: Icad2e6136218486a439e3c5ed0296462e3c3c4e6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/310020
Commit-Queue: Stephen Adams <sra@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
The bug can be occur when 2 Dart2JS apps load on the same page but 1 uses a version of the Dart2JS runtime prior to https://dart-review.googlesource.com/c/sdk/+/309361 and the other uses the runtime from after 309361. If the one from before 309361 loads onto the page first, the `$__dart_deferred_initializers__` will be initialized without `eventLog`. Then the second app will load and see that `$__dart_deferred_initializers__` is present and try to add to `eventLog`, but `eventLog` will not be present.
This would cause an exception in the Dart2JS runtime and probably prevent the page form loading correctly.
Change-Id: I05b17867e24ae80cb4d7cdc615c8b985321912f5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/309761
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
The only entities specific to the K- model are `KLocalFunction` and `KLocalTypeVariable`. I've copied these both (as is) to the J- model.
The only thing we "lose" here is the calls to `checkFamily` in `kernel/element_map_impl.dart`. Given how interchangable the 2 models were, this wasn't adding much value anyway.
Since there is still a distinction between the K- environment and J- environment, we can now think of that conversion as being between a `J` and `J'` environment where the semantics are slightly different (e.g. `J'` has closure conversion applied).
Using the same model also makes it easier to have more intermediate states of the `J` model. For example, we might keep around the `JLocalFunction` nodes until SSA and do closure conversion at that point instead.
Change-Id: If149241725a03b8de6aba6d486506434529b998d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/306980
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Adds an "eventLog" property to the global "$__dart_deferred_initializers__" object. The event log is just a JS Array that gets initialized alongside $__dart_deferred_initializers__.
Each event entry is a String->String JS object. I unified the format of these event objects for easier parsing.
Each printed event is now valid JSON (passed through JSON.stringify) so we can more easily post-process the logs if necessary.
Fully replacing the existing "_eventLog" field makes the logging logic simpler. Having a single array allows us to not include a timestamp because the array captures the event ordering (actual timing doesn't matter). It also makes it easier to stringify the logs when there's only 1 data source/format.
Sample output:
```
{"hunkName":"out.js_1.part.js","event":"loadHunk"}
{"uri":"path_to/out.js_1.part.js","hunkName":"out.js_1.part.js","event":"downloadHunk"}
{"file":"out.js_1","event":"beginLoadPart"}
{"file":"out.js_1","event":"endPartLoad","hash":"aCscY7yv4EHodRPmCqYn5BqMelA="}
{"uri":"path_to/out.js_1.part.js","hunkName":"out.js_1.part.js","event":"downloadHunkSuccess"}
{"hunkName":"out.js_1.part.js","hash":"aCscY7yv4EHodRPmCqYn5BqMelA=","event":"initialize"}
```
Change-Id: Ifee73be0bf7dc53a0e7710ff033dd2b0fae9fb0e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/307240
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
This annotation is unneeded as named arg external constructors
is enough to determine if an object literal is created. The one
exception is an empty object literal, but our guidance is to use
utility functions to create one instead. This is a better fit for
that purpose too as an interface for an empty object literal is
more uncommon.
CoreLibraryReviewExempt: Backend-specific library.
Change-Id: I10cf891601b28ff7e56129842d099ea28863626d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/307506
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Joshua Litt <joshualitt@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Fixes issue with platform binary getting included twice in Flutter builds leading to issues with type erasure and factory constructors.
Tested internally on sequential, non-sequential, modular and Flutter builds. All executed normally.
Change-Id: I359d98f51629364efa5f9e00c748eccc20261ad4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/306683
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Some large programs are still hitting this limit on type nodes that would otherwise converge.
We can set this limit arbitrarily high to avoid the chance of any node that will converge from hitting it. We are still maintaining the metric and check and continuing to monitor internally. However, confirmed that several large apps that were hitting the 12 limit are now fully refining all nodes.
Change-Id: I17be593a69dac4490cde92506e405d305f3c9b16
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/306561
Reviewed-by: Mayank Patke <fishythefish@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
The UnionTypeMask k-limit can cause cycles in the type graph to end up in an infinite loop where they continually widen and narrow. The solution is to ensure monotonicity of these union operations, if we are attempting to go from a FlatTypeMask to a UnionTypeMask, the UnionTypeMask should be strictly wider than the FlatTypeMask.
Change-Id: I32ec0927c7c7863a5f093df7c087b19ef3f1bc01
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/296480
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
Currently _narrowType for TypeInformation nodes has logic to process DartTypes. This logic is a simplified version of the logic in createFromStaticType. We can consolidate the two and just use createFromStaticType directly.
And since the static type is only ever used for this type narrowing (and its immutable) we can create the AbstractValue up front and store that instead of the DartType.
There was no difference in the emitted JS when tested on 2 large programs.
Change-Id: I432279684580edf64ff52254653bd26501d461b7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/304160
Reviewed-by: Mayank Patke <fishythefish@google.com>
Adds a delegating reporter so we can keep track of whether there are
interop errors. If there are, we do not do the transforms on the JS
backends.
Change-Id: Ib0f36b748443cb7fe8f8bb427692d653557d59fa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/304261
Reviewed-by: Joshua Litt <joshualitt@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Due to the introduction of "virtual parameters" (parameters of virtual functions) there was a new pattern that allowed for non-converging types. If two functions are mutually recursive and one makes a virtual call to the other, then we end up with a cycle in the parameter types.
That part isn't new, that cycle already existed. However, now the cycle can include the virtual parameters for those functions. The way we enqueue the users after resolving a virtual parameter can cause an alternating pattern of refinement that doesn't allow the cycle to fully resolve itself.
We resolve this by manually enqueueing the concrete parameter and its associated NarrowTypeInformation (which enforces the static type). The key is that these are enqueued before other users of the virtual parameter which in the bad case are other members in the cycle that were being processed out of order.
Change-Id: Ic20afcc55ca6e75152d7858eaab1cb24a57ea20e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/303120
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
Maintains functionality of existing '--write-X-uri' and '--read-X-uri' but also introduces new '--stage' flag that indicates which phases of the compiler should run.
Also expands the behavior of the `--output` flag to support taking a file prefix and/or an output directory that files are written out to.
Valid invocations can look like:
`dart2js main.dart --stage=cfe`
`dart2js main.dart --stage=cfe --output=prefix1-`
`dart2js main.dart --stage=cfe --output=/some/path/`
Change-Id: If90fb16f549d35f16f77d660c51f8d28673e454f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/300520
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
This change locks down the Dart2JS command line API to the few invocation flows we use today:
1) Full compile from Dart sources.
2) Full compile from pre-compiled dill sources (modular CFE).
3) Phased compilation from Dart sources.
4) Phased compilation from pre-compiled dill sources (modular CFE).
It also ensures that each phase is run individually (accounting for sharding in codegen/emitter).
There are already places in the code where we assume that Dart2JS will be invoked in one of these ways so this should codify those assumptions.
Change-Id: I4e2a85d123e0c2ad924e2dd1b230548a995af0da
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/299760
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
This was added before null safety, and before we had fully
defined the difference between Null, Bottom, and Never types.
I believe now this and Never.nonNullable are equivalent and
the distinction is no longer important to make. Hence, I'm
deleting it to reduce tech debt.
Originally this was added in https://dart-review.googlesource.com/c/sdk/+/88961
Change-Id: I64b3a8b01833bc60305eaecf430bfb249c8d2c98
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/301820
Reviewed-by: Mayank Patke <fishythefish@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
