This change makes sure that
JS('JavaScriptFunction', '...', ...)
actually registers `JavaScriptFunction` and its superclass `LegacyJavaScriptObject` as instantiated.
Bug: #56533
Change-Id: I977f149cff97b0a5f42d69f303664f5a70cb401c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/381820
Reviewed-by: Mayank Patke <fishythefish@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
This reverts commit 1057e5575f.
Reason for revert: Breakage in product test
Original change's description:
> [dart2js] Make more use of kernel's static type
>
> This change helps with one hang-over from Dart 1.
>
> In code like `a[i] == 1`, the type of the indexed element was inferred
> as the element type of `a`. This was great if `a` was a traced List,
> but too general if the provenance of `a` is unknown, since the general
> element type over all lists is 'top'.
>
> Dart 3 gives much better guarantees than Dart 1. We can now rely on
> the front-end inferred type for `a[i]`. To do so, we track the
> abstract value contraint for the type through SSA so that SSA-level
> type propagation can re-apply the constraint.
>
> This removes about 100 interceptor calls from the main unit of some
> large ACX apps.
>
> Change-Id: I6839a6045d9341633c08678affb35fdb2998a96d
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/379145
> Reviewed-by: Mayank Patke <fishythefish@google.com>
> Commit-Queue: Stephen Adams <sra@google.com>
Change-Id: I5e2b9fde9ffd7d79332fd493649e8f342219c8ea
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/379667
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
This change helps with one hang-over from Dart 1.
In code like `a[i] == 1`, the type of the indexed element was inferred
as the element type of `a`. This was great if `a` was a traced List,
but too general if the provenance of `a` is unknown, since the general
element type over all lists is 'top'.
Dart 3 gives much better guarantees than Dart 1. We can now rely on
the front-end inferred type for `a[i]`. To do so, we track the
abstract value contraint for the type through SSA so that SSA-level
type propagation can re-apply the constraint.
This removes about 100 interceptor calls from the main unit of some
large ACX apps.
Change-Id: I6839a6045d9341633c08678affb35fdb2998a96d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/379145
Reviewed-by: Mayank Patke <fishythefish@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
Closes https://github.com/dart-lang/sdk/issues/54381
- Adds an API to capture the this value so that users
can use it in the callback.
- Adds specialized stubs to dart2js similar to what was
done for toJS.
- Adds generic stub to DDC as these stubs don't get
tree-shaken away and toJSCaptureThis is less likely to be
used.
- Modifies dart2wasm lowerings to add this to the JS
function wrapper if calling toJSCaptureThis.
Change-Id: Ic0a7fd768de1dd6b491998e029ff5eb406ee7992
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/377160
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
before adding check in caller
This wasn't needed when the required null checks were keyed on member
entities. Since we now use selectors as keys instead, it's possible for
a selector to be marked as requiring caller-side checks even though not
every associated member requires one.
Change-Id: Ibe4be750e4d3dd02f97e8d27efa29a1c7904e2bd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/375420
Reviewed-by: Nate Biggs <natebiggs@google.com>
Commit-Queue: Mayank Patke <fishythefish@google.com>
- Add SSA HArrayFlags{Check,Get,Set} instructions to check for
fixed-length and unmodifiable JSArray and JavaScript typed data
instances.
- Add optimizations to remove redundant checks.
- Added HOutputConstrained interface for instructions that must have
the input and output in the same JavaScript variable. This
generalizes some code generation logic already applied to HCheck.
Bug: #53785
Change-Id: I61750dd03aa3a964eed3bc76e1656c5f60f77109
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/372002
Commit-Queue: Stephen Adams <sra@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
Introducing a partial redundancy with a variable with a longer
live-range can reduce the size of the emitted code.
Flute.complex (-O4): -0.377%
cm_shell (-O4): -0.029%
Change-Id: I0d03119b17f4b58d61f277bf8bb0e57d8e7c47c5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/360360
Reviewed-by: Mayank Patke <fishythefish@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
I noticed that dart2js generated poor code for `(a, b) = (1, 2)`.
This is due to an oversight in not constant-folding record field loads.
Change-Id: Iac110d8c3373d7673c21494fc467f7fcb400de1d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/371505
Commit-Queue: Stephen Adams <sra@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
Internal users reported a compiler crash when using sequential compilation. Their change involved adding a class hierarchy in which the constructor of a superclass included a RecordIndexGet. When analyzing the constructor of the subclass we also analyze the body of the super constructors.
In this rare case the member being analyzed does not match the member containing the receiver node. Usually calls act as a layer of indirection that we do not analyze across.
When we then save the type of the receiver, we do so in the context of the wrong member (the subclass constructor rather than the superclass constructor). We just have to be more careful to use the correct context member.
The added test fails prior to this change.
Change-Id: I8b9a3b8a7692b8604d5c37c59b94bb8d46afff75
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/371580
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
This CL adds a new --interop-null-assertions flag (cf.
--native-null-assertions) with the goal of validating that JS interop
APIs with non-nullable static return types do not return null values.
This flag is currently disabled by default but is intended to assist in
sound null safety migrations.
In general, we don't guarantee type soundness of package:js interop
since users can write incorrect static types which are not backed by
any runtime checks. However, it is likely that during the null safety
migration, some interop APIs which should have been made nullable
weren't. Therefore, we want to offer some additional (but limited)
checking for this case.
For static invocations of functions with non-nullable return types, we
can simply perform a null check on the result of the call.
For instance methods (which could be invoked virtually/dynamically), we
want to perform a null check on the return value in the callee (the
interceptor method) itself when possible.
It's possible for multiple interop bindings to share the same
interceptor method. We produce a null check in the interceptor method
body if all the methods have non-nullable return types. Otherwise, we
insert checks at callsites when appropriate.
Change-Id: Ifd155d7f8326152b6d57d61199e0b7973c4a1211
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/369784
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Mayank Patke <fishythefish@google.com>
If the enclosing class is a leaf node search for live matches in "canHit". Do this by iterating the class hierarchy starting at the enclosing class of the element and checking the supertype to see if they're included in the constraint set.
Change-Id: If859bbca1d2744303c03ac91d1601a05c61dfc2d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/367220
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
The change adds a new reduction that recognizes the construction of a type environment from components
HTypeBind(HTypeEval(env, e1), HTypeEval(env, e2))
and replace with an equivalent expression that constructs the same derived type environment directly
HTypeEval(env, ...e1...e2...)
This change speeds up the benchmarks that iterate `Map.entries` by roughly 10-25%.
---
Type arguments are passed as separate values [1]. This means that the generative constructor factory `MapEntry<K,V>(this.key, this.value)` has four parameters - `MapEntry$(key, value, $K, $V)`. The passed arguments usually come from the same place, perhaps extracted from the type of the current object, `this.$ti._eval("1")` and `this.$ti._eval("2")`.
Inside `MapEntry$`, the type parameters are re-assembled into a type environment:
$K._eval("@<0>")._bind($V)
which is used to construct the object type
$K._eval("@<0>")._bind($V)._eval("MapEntry<1,2>")
After inlining:
$K = this.$ti._eval("1");
$V = this.$ti._eval("2");
$K._eval("@<0>")._bind($V)._eval("MapEntry<1,2>")
After GVN, and reducing the adjacent `._eval("1")._eval("@<0>")` to `._eval("@<1>")`:
t1 = this.$ti
t1._eval("@<1>")._bind(t1._eval("2"))._eval("MapEntry<1,2>")
The new reduction gives us:
this.$ti._eval("@<1,2>")._eval("MapEntry<1,2>")
which can be reduced further by combining adjacent HTypeEvals:
this.$ti._eval("MapEntry<1,2>")
[1]: It would be better to pass the type arguments as a single Rti object to avoid the extract-recombine pattern, but changing the calling convention is a more extensive change. In the meantime, this reduction cleans up the extract-recombine pattern when inlining brings the parts together.
Change-Id: I28801ce5d952d0f4e5ac1d55c252766159dcceef
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/367240
Reviewed-by: Mayank Patke <fishythefish@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
The dart2js binary serialization infrastructure only supports 30 bit integers with the "writeInt" method. The indexing infrastructure uses 1 of the bits to store locality information leaving 29 bits to encode the address space.
The recent dump info changes expanded the address space of some large programs beyond this 2^29 and is causing some serialization issues when trying to generate dump info.
The solution here is to check when an address is above 2^29 and instead encode the offset as a uint32. This will use 5 bytes for these large values (1 for the large offset indicator and 4 for the offset itself). By doing this we expand the address space to 2^32 which is more than enough to support larger programs.
An alternative would be to use some bits from the indicator and encode the rest in a separate 30-bit int. This would allow us to represent an address space closer to 2^60. But we would need to use an extra bit to differentiate the indicator and an actual offset. Which would reduce the base address space to 2^28 causing us to hit the more expensive 5-byte case earlier and increasing total write size. No known program is anywhere near the 2^32 address space size so the larger address space is not necessary.
Change-Id: Icbed2961099842ebf286b36314e8d6fab7389db4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/363541
Reviewed-by: Mayank Patke <fishythefish@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
By having _addImplicitChecks add all the checks to implicitIsChecks before recursing into them, we avoid exploring each new check via recursion.
For a wide enough class hierarchy where one check implies many other checks, the recursive visiting pattern could lead to stack overflows.
Change-Id: I7f50af4e8c0859ac77da143ade68cc3d9e2cc503
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/362403
Reviewed-by: Mayank Patke <fishythefish@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
Before TFA runs, MixinFullResolution will clone a mixin's fields into the application classes for that mixin. The cloned Field on the application class will have a fileUri that refers to the original mixin file.
However, TFA then copies those fields into FieldInitializers which don't have a fileUri context and so the fileUri for the surrounding Constructor is used. This leaves expressions in the initializer with offsets relative to the mixin's file but in the context of the mixin application's file.
To fix this, we can wrap the initializer in a FileUriExpression referring to the original mixin class. We only do this if the field the initializer is copied from refers to a different file than the target constructor.
Also add handlers for FileUriExpressions to several visitors that don't already support this new AST node.
Change-Id: I47b0d48dfe87303949130a40216b199949cfa1d9
Tested: Existing test suite.
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/360420
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Today to invoke Dart2js with sequential actions there are 2 ways to specify the stage from the command line. By specifying a `write-<stage-data>=<some-uri>` or by using `stage=<some-stage>`. Internally we use the former via a similar (but separate) concept to Dart2jsStage. The goal here is to consolidate all these different entry points.
The new CLI works as follows:
- To run the compiler in full you can:
- Pass no additional flags as before
- Specify 'stage=all'
- 'dump-info-all' runs the full compilation from scratch but includes
dump info.
- To run the compiler in sequential mode you specify a stage:
- Each stage has its own name passed to the '--stage' flag.
- All the intermediate data URIs can be passed to every stage and only
the relevant ones are used for any given stage. If no URI is passed
then a default URI is used.
- 'dump-info' is now its own stage. Partial dump info data is
always included in the emit-js and codegen-emit-js steps.
- 'cfe-only' flag is maintained for compatibility with Flutter CLI.
Change-Id: I67965d7708688a85c866d8abef3716bee23a083f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/358740
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
25 hits in FluteComplex.
Many come from APIs with `[start, end)` range arguments that are unused so `length = end - start` is now optimized to `end`.
Change-Id: I59527f85323bed717d62249f0c1d69b477645ec2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/360444
Commit-Queue: Stephen Adams <sra@google.com>
Reviewed-by: Nate Biggs <natebiggs@google.com>
When dump info data is being serialized as part of the codegen + emitter joint phase, all the impacts are considered "generated" and so they must all be serialized with the dump info data. If we wait to serialize them until the end of the phase as we usually do, these impacts cannot be GCed right away. This leads to a much higher memory footprint. By serializing them eagerly we can GC the object and just maintain the much leaner serialized data.
Change-Id: I11606f7291fe8d86af1f72724bd8c68e9666a00a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/359300
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
Currently, serialized dump info metadata (output of emitter phase) contains all the impacts created during codegen in a Map<MemberEntity, WorldImpact>. These impacts are already serialized in the output of the codegen phase. This is bad for two reasons: 1) The serialized bytes are duplicated. 2) The impacts cannot be GCed right after the emitter uses them, the dump info registry maintains a reference to them.
To mitigate this I've updated the registry to only store impacts for entities where the impacts are generated during the emitter phase (today only parameter stubs). Rather than try to re-generate those impacts during the dump info phase, we serialize them with the dump info metadata. However, most impacts are generated during the codegen phase and for these we deserialize them from the codegen results at the beginning of the dump info phase.
Change-Id: I1302b4ab759bca3d492bc6b40194d7a7720ed6f8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/354580
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Ensuring HInstruction.inputs is always a growable list allows ~650
calls to be devirtualized* and makes the output of `dart compile
aot-snapshot dart2js.dart` about 0.1% smaller. I was not able to detect a significant performance difference in the SSA phase time.
* Estimated from indirect indexed addressing mode calls in the disassembly.
Change-Id: I330cd42299d994669bf7a1e2303497b4bbdb827c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/354160
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
Adds a conditional impact that represents that impact if the replacement node is added to the kernel AST. This is a soundness fix for conditional impacts as the replacement node might have a different set of impacts than the "source".
It's worth noting that the only way this could lead to an incorrect compilation for protobufs is if *every* metadata field was erased. The impact of each "source" is a superset of the impact for every "replacement" node.
This code is new and behind a flag so this bug certainly won't have been visible to anyone.
Change-Id: Ifa3cb7d6b9aa46221c736a1566aa79d73f99917c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/353940
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
Stephen Adams