This migrates the `String` implementation from using JS interop to
explicit host imports for the standalone target.
This moves a few helper methods shared between the JS and standalone
targets to `dart:_string_helper`. This also moves the embedder regexp
implementation to `dart:_string` to be able to access internals in some
string methods (similar to how the JS implementation special-cases
`JSSyntaxRegExp`).
This removes the final real use of JS-interop in the standalone target.
So, we can:
- Remove internal JS helper libraries from the target.
- Skip JS-interop transformations in the compiler.
- Stop emitting a helper module and support script.
Because `js_interop` is imported in `dart:_wasm`, we can't remove the
library entirely. This replaces it with a stub to avoid compilation
errors, a proper removal is tracked in dartbug.com/63166.
Change-Id: Ide495c210c3a272438deebf8fe4f3f44ba314ffa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/501960
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Kevin Moore <kevmoo@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
The former contents of the VM isolate are now included into each isolate group. This makes each isolate group's heap independent, and in particular allows each heap to be allocated to a separate pointer cage (not done in this CL).
The duplicated stubs that allowed PC relative calls are removed, since the originals can now be the target of PC relative calls.
The bootstrapping needing to load an AppJIT or AppAOT snapshot is reduced to allocating the oddballs. The code is entirely dropped in the AOT runtime, but the JIT runtime still has it to allow for flags to affect the compilation of the stub code. Further refactoring might be able to remove this for the JIT runtime too, with only gen_snapshot knowing how to bootstrap.
Class serialization no longer distinguishes predefined classes.
The page containing null is marked as never-evacuate. null, false and true must not move because the compiler relies on their low bits having certain patterns for some optimizations. (Previously, the entire VM isolate heap never moved.)
Compaction is disabled for IA32. Due to register pressure, some stub calls must not use a scratch register and embed the address of Code.
The page containing the call-through-safepoint stub is frozen when running with --write-protect-code and the stub is created at runtime (instead of loaded from an AppJIT or AppAOT snapshot). This stub must remain executable even during a safepoint, as a foreign call might during return during a safepoint and only block after the stub directs it to the runtime.
The snapshot symbols are renamed to kDartSnapshotData and kDartSnapshotText. There is no need to distinguish the VM isolate's snapshot, and snaphots are per isolate group not per isolate. Aliases with the old names are added to ease migration.
Some global flags that were automatically set based on the VM isolate's snapshot are now isolate group flags and automatically set by the isolate group's snapshot.
TEST=ci
Change-Id: Iee82016057d609112e9b021d178fc3d4d18b5044
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/500621
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Tess Strickland <sstrickl@google.com>
SLSA-Policy-Verified: SLSA Policy Verification Service <devtools-gerritcodereview-exitgate@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
It is disabled when augmentations feature is enabled.
This is not a breaking change, because CFE did report this error.
The relevant reason is indirect, not a single sentence saying “on A
implements A is forbidden”.
Spec chain:
1. In dartLangSpec.tex:6019, a mixin declaration is modeled as:
`mixin N<T...> on T1, ..., Tn implements I1, ..., Ik { ... }`
2. In dartLangSpec.tex:6065, the mixin interface M_I is defined as if
by:
`abstract class N<T...> implements T1, ..., Tn, I1, ..., Ik { ... }`
and dartLangSpec.tex:6078 says it is a compile-time error for the mixin
if that synthetic class declaration would be a compile-time error.
3. In dartLangSpec.tex:5189, class superinterfaces say:
It is a compile-time error if two elements in the type list of the
IMPLEMENTS clause of a class C specifies the same type T.
So:
`mixin M on A implements A {}`
is checked like:
`abstract class M implements A, A {}`
which violates the duplicate implements type rule.
Change-Id: I29e5fa17c47d111346ef6a6e321ab5dbab985ad1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/503501
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
https://dart-review.googlesource.com/c/sdk/+/498840 added support for
promotion of properties (private, final instance variables with a name
which isn't used much for other purposes) in the context of anonymous
methods.
This CL reduces the set of situations where this feature is enabled such
that only `this` will allow property promotions to be carried in (such
that `this._x` is promoted in `v.=> this._x` when `v` is such that
`v._x` has been promoted before the anonymous method occurs). It also
generalizes the mechanism such that property promotions are carried out
(so we can do `if (v.=> _x is int) v._x.isEven;`).
Tests has been adjusted accordingly.
Change-Id: Ibe70713d3d9c89a6d95f9c3dd28df8f147cb518d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/502660
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
When deferred loading was enabled the dynamic dispatch class ID table
was incorrectly assigning class IDs to the wrong module. If a contiguous
target segment included classes/targets from different modules, all of
them were getting assigned to the module of the first class/target in
that segment.
This was causing spurious NSM exceptions as the necessary rows in the
table might not be populated for a dynamic call if the module the
segment was assigned to wasn't loaded yet.
To fix this we end the segment if the next target does not belong to the
same module as the active segment.
The new test fails with an NSM exception prior to this fix.
Change-Id: I07bc4fdb5a8bff1bfad5fe17f45c8076a965a775
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/502860
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Adds two new getters to int for bit-counting: trailingZeroBitCount
(ctz) and oneBitCount (popcount). On native platforms they operate
on the full 64-bit two's-complement representation; on the web they
operate on the least-significant 32 bits.
Implementations:
- VM: unified C++ natives Integer_trailingZeroBitCount /
Integer_oneBitCount on _IntegerImplementation, using
Utils::CountTrailingZeros64 and Utils::CountOneBits64. The receiver
may be _Smi or _Mint at runtime.
- dart2js / DDC: clz32-based ctz and a SWAR popcount.
- dart2wasm: inlined i64.ctz and i64.popcnt intrinsics.
leadingZeroBitCount (clz) is intentionally excluded from this CL: its
result depends on the platform integer width (e.g. 1.leadingZeroBitCount
is 31 on web, 63 on native), and the same value can be derived from
the existing bitLength getter when needed.
Asm intrinsification on native architectures is intentionally left for
a separate follow-up CL.
Work towards https://github.com/dart-lang/sdk/issues/6486 (this CL
covers popcount and ctz from the bit-twiddling list; clz, rotate,
reverse, and others remain).
Work towards https://github.com/dart-lang/sdk/issues/1053 (efficient
BitSet implementation).
Bug: https://github.com/dart-lang/sdk/issues/52673
Bug: https://github.com/dart-lang/sdk/issues/38346
TEST=tests/corelib/int_bit_count_test
Change-Id: I8a5cdb5c91360478f47bbd6b9c84ca1c477aa8c7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/498041
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Auto-Submit: Modestas Valauskas <valauskasmodestas@gmail.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
In some cases, closure contexts were being left out of the parent chain
of their children because they were empty at the time the child closure
was created. If a usage appeared later in the visit of the parent, the
context would no longer be empty but the child would already be created
without a parent.
This was easiest to recreate in sync* function because unlike async, it
doesn't introduce hoisted helper variables (these immediately mark the
parent as non-empty).
In the attached bug the repro only happens with named parameters because
TFA transforms the named parameter into a Let that introduces a variable
before the closure with the usage in the let body after the closure. The
new test explicitly introduces the same pattern of a variable declared
before the closure and used after it.
The fix here is to not eagerly check for emptiness of the parents.
Instead we post-process the Contexts and relink the parent tree skipping
any empty nodes.
Bug: https://github.com/dart-lang/sdk/issues/63264
Change-Id: I2f75506b9fa879544b1a606d8f157fbd44ba8ce2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/500680
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
This CL adds support for promotion of certain private final instance
variables along with anonymous methods. The promotions do not differ
from the ones which are already available in Dart without anonymous
methods, but it requires some generalizations to handle the changing
value of `this` which is made possible by anonymous methods.
Change-Id: I720a5fa6d29a8a7d19bb2e167dc135f97492b525
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/498840
Reviewed-by: Paul Berry <paulberry@google.com>
This adds an AsyncModifier class that holds both the AsyncMarker, used in the kernel encoding, and the file offset of the async modifier. This is used throughout the front end and ensures that the correct offset is used for errors reported on the async modifier.
Change-Id: If16d293ffb9b2e8fa8eca8c65f7548d920c5d56b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/500720
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Kallen Tu <kallentu@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This CL enables the primary constructors feature by default in Dart 3.13.
The primary constructors feature is a brevity feature. There are no new semantics, but it allows us to express declarations in a less verbose way.
This feature allows one constructor and a set of instance variables to be specified in the header of a declaration.
Currently a declaration with a constructor and some fields is written as:
```dart
// Current syntax.
class Point {
int x;
int y;
Point(this.x, this.y);
}
```
With a primary constructor, we would write the above as:
```
class Point(var int x, var int y);
```
If a primary constructor needs an initializer list or a body, they can be
specified inside the class using the `this` body syntax:
```dart
class Point(var int x, var int y) {
this : assert(x >= 0) {
print('Point created at $x, $y');
}
}
```
As part of this feature, you can also use the `new` and `factory` keywords to
declare constructors in the class body without repeating the class name:
```dart
class Point {
int x, y;
// Equivalent to Point(this.x, this.y)
new(this.x, this.y);
// Equivalent to Point.origin()
new origin() : x = 0, y = 0;
// Equivalent to factory Point.clone(Point other)
factory clone(Point other) => Point(other.x, other.y);
}
```
To learn more about the feature, check out the feature specification located here: https://github.com/dart-lang/language/blob/main/accepted/future-releases/primary-constructors/feature-specification.md
Tested: Has existing language, CFE, analyzer, analysis server tests.
Bug: https://github.com/dart-lang/sdk/issues/61524
Change-Id: I296f2fcd918b87bf2a1dd00256340759866c2423
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/489241
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Michael Thomsen <mit@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
This reverts commit 3eb697c0af.
Reason for revert: Internal Google3 breakages
Original change's description:
> [flow analysis] Fix unsound type promotion in inner async/generator functions.
>
> An `await` expression or `yield` statement suspends the current
> function and allows other code in the same isolate to execute. In the
> case of nested functions, an `await` or `yield` in the inner function
> can allow the outer function to continue executing. That means that if
> the inner function promotes a local variable belonging to the outer
> function, then it isn't sound to carry that promotion past an `await`
> or `yield`.
>
> This change fixes the unsoundness by adding a flow analysis method
> `suspension`, which the shared type analysis logic uses to tell flow
> analysis that an `await` or `yield` has been found. The `suspension`
> method un-does the promotions of any variables that might be written
> to while the inner function is suspended.
>
> Fixes https://github.com/dart-lang/sdk/issues/62889.
>
> Change-Id: I77eaf997159819a7c50f44b67174d2aa6a6a6964
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/499382
> Reviewed-by: Johnni Winther <johnniwinther@google.com>
> Commit-Queue: Paul Berry <paulberry@google.com>
> Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
> Reviewed-by: Bob Nystrom <rnystrom@google.com>
Change-Id: I187ba9a347394946ecc8749d35dc7914d271b90a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/500540
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Paul Berry <paulberry@google.com>
`List.unmodifiable` and `Map.unmodifiable` is as badly typed
as `List.from` and `Map.from`, but does not have a better-typed
`.of` constructor. This adds such, to give a migration target
when deprecating the badly typed constructors.
The `Future.delayed` with no second argument is also unsafely
typed, it fails if the type argument is not nullable.
The `Future.pause` creates `Future<void>` instead.
CoreLibraryReviewExempt: No new or platform specific behavior.
Change-Id: Iba101b3dc62f412003abd501fa042aca0ce63116
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/499280
Commit-Queue: Lasse Nielsen <lrn@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
An `await` expression or `yield` statement suspends the current
function and allows other code in the same isolate to execute. In the
case of nested functions, an `await` or `yield` in the inner function
can allow the outer function to continue executing. That means that if
the inner function promotes a local variable belonging to the outer
function, then it isn't sound to carry that promotion past an `await`
or `yield`.
This change fixes the unsoundness by adding a flow analysis method
`suspension`, which the shared type analysis logic uses to tell flow
analysis that an `await` or `yield` has been found. The `suspension`
method un-does the promotions of any variables that might be written
to while the inner function is suspended.
Fixes https://github.com/dart-lang/sdk/issues/62889.
Change-Id: I77eaf997159819a7c50f44b67174d2aa6a6a6964
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/499382
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Coercion from `dynamic` to a non-top type has observable effects,
since it may throw an exception. Therefore it's important that any
tree manipulations that are performed as part of type inference (such
as hoisting of named arguments that precede unnamed ones) preserve the
order of coercions relative to expression evaluation.
Prior to this change, the following code:
f(n: e1, e2)
Would get transformed into:
let tmp = e1 in f(coerce(e2), n: coerce(tmp))
And so the coercion of e1 would not happen until after the evaluation
of e2.
With this change, the code is transformed into:
let tmp = coerce(e1) in f(coerce(e2), n: tmp)
Which (correctly) coerces e1 before evaluating e2.
Fixes https://github.com/dart-lang/sdk/issues/63150.
Change-Id: Iee33c162c7cc3a9b0a8b03bde211bf926a6a6964
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/498980
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This gives around 0.2% improvement in compressed e main module.
In Dart a function with `void` return type can actually return values
that callers can observe. But most of the time this doesn't happen, most
times those functions return `null` values and callers don't observe
them.
Let's use inferred return value information to see if a function is
guaranteed to only return `null`. If so we make the wasm function
signature not return any values. Callers will then synthesize a `null`
which may immediatly be dropped or (in rare cases) actually be used.
This leads to less less instructions in the callee (as a callee doesn't
need to push the null onto the stack) and the caller (as the caller
doesn't have to drop it from the stack).
Change-Id: I3ed1be7592798ad0c697c5bc3ab2c4b64c156f03
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/497620
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
This is a reland of commit e7dbd6ba48
Original change's description:
> [dart:js_interop] Make JSFunction and JSExportedDartFunction generic
>
> Fixes https://github.com/dart-lang/sdk/issues/54557
>
> The generic type in JSExportedDartFunction corresponds to the
> static type of the function it wrapped, whereas for JSFunction,
> it's purely a descriptor of the JS function.
>
> When calling JSExportedDartFunction, a cast is now introduced
> to cast it to T.
>
> When calling isA, the type in JSExportedDartFunction is passed
> along to check that the value that is wrapped is that function
> type. Because the T in JSFunction is descriptive, e.g.
> isA<JSFunction<int Function()>>() does no such check.
>
> ____
>
> Also cleans up:
>
> - isA<JSTypedArray>() logic to use intrinsic functions
> - some expectation files to be consistent for both dart2js and ddc.
>
> CoreLibraryReviewExempt: Backend-specific library with needed reviews.
> Change-Id: I1a55c4386e416fa4ccabe06ac5051f41c2e2e95a
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/496820
> Reviewed-by: Lasse Nielsen <lrn@google.com>
> Commit-Queue: Srujan Gaddam <srujzs@google.com>
> Reviewed-by: Martin Kustermann <kustermann@google.com>
CoreLibraryReviewExempt: Reland.
Change-Id: I29d706aa4967fd80390e8cb37f8144603ec007f5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/498100
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Call sites targeting a procedure annotated with `external-effect` will
not produce any code, including the argument which will not be
evaluated.
However, the single parameter will be treated as 'live' for the purposes
of any global analysis the backends do. This is useful for things like
protobuf shaking where a user may want to retain certain protobuf
messages without actually emitting the code that retains those messages.
Today this functionality is available internally in the vm and wasm SDK
libraries. dart2js has similar functionality represented via the
opaqueTrue and opaqueFalse booleans (which will cause conditional
branches to get shaken after analysis). This will replace dart2js's
opaque(True/False).
This also adds validation to the frontend to ensure a method annotated
with 'external-effect' is well-formed.
Change-Id: If1c4096673e655c58fe7638840a16125003e7809
Tested: Backend tests for codegen were added. A frontend test was added for the validation. A language test was added to confirm the behavior.
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/476020
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
dart2wasm imports strings as globals for which JavaScript engines would
provide the respective values. The standalone target needs to support
all WebAssembly runtimes, so it can't rely on this mechanism.
Instead, this imports functions to convert a WebAssembly arrays of char
codes or ASCII bytes into a string. For now, these functions have to
return JS strings since the rest of the SDK relies on that. In the
future, embedders would be able to return any string implementation as
an externref.
Because calling host functions is invalid in constant contexts, string
constants can't be regular globals. For now, this uses the default
non-eager constant implementation with one initialization function per
string constant. Eventually, we should probably initialize these
strings in a WASM start function instead.
TEST=pkg/dart2wasm/test/standalone_test.dart
Change-Id: I93b7c3846fbe99daa8ffa31e452f62672b61ce4b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/495020
Reviewed-by: Nate Biggs <natebiggs@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
I changed the parsing of const dot shorthands to parse the entire selector chain in `parsePrecedenceExpression` rather than parsing them in `parseConstExpression`. We were originally parsing the initial expression before the `.` and only flagging that as a dot shorthand which prevented any chaining on const constructors. Const expressions with chained methods/property accesses were not being flagged as a dot shorthand so we weren’t saving the context type properly which led to producing the “unknown context type” error.
Before:
```
class C {
const new someConstCtor();
C method() => this;
}
C c = const .someConstCtor.method();
// (const .someConstCtor) is parsed and handled as a const constructor
// (const .someConstCtor) is handled as a dot shorthand, context is
// saved on only this AST and not the outer chain.
// Then we parse the rest of the selector chain (.method())
//
// Error: No context type for (const .someConstCtor.method())
```
After:
```
class C {
const new someConstCtor();
C method() => this;
}
C c = const .someConstCtor.method();
// (const .someConstCtor) is parsed and handled as a const constructor.
// Then we parse the rest of the selector chain (.method())
// (const .someConstCtor.method()) is handled as a dot shorthand, context is saved for this outer node.
//
// OK. No error because we are able to retrieve the type for the
// entire dot shorthand chain.
```
Fixes: https://github.com/dart-lang/sdk/issues/63119
Change-Id: I3308d8eb7ce101466be257aba6b5448921bff136
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/495560
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
This reverts commit e7dbd6ba48.
Reason for revert: Broke flutter_analyze
Original change's description:
> [dart:js_interop] Make JSFunction and JSExportedDartFunction generic
>
> Fixes https://github.com/dart-lang/sdk/issues/54557
>
> The generic type in JSExportedDartFunction corresponds to the
> static type of the function it wrapped, whereas for JSFunction,
> it's purely a descriptor of the JS function.
>
> When calling JSExportedDartFunction, a cast is now introduced
> to cast it to T.
>
> When calling isA, the type in JSExportedDartFunction is passed
> along to check that the value that is wrapped is that function
> type. Because the T in JSFunction is descriptive, e.g.
> isA<JSFunction<int Function()>>() does no such check.
>
> ____
>
> Also cleans up:
>
> - isA<JSTypedArray>() logic to use intrinsic functions
> - some expectation files to be consistent for both dart2js and ddc.
>
> CoreLibraryReviewExempt: Backend-specific library with needed reviews.
> Change-Id: I1a55c4386e416fa4ccabe06ac5051f41c2e2e95a
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/496820
> Reviewed-by: Lasse Nielsen <lrn@google.com>
> Commit-Queue: Srujan Gaddam <srujzs@google.com>
> Reviewed-by: Martin Kustermann <kustermann@google.com>
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Change-Id: I98447c8c95906feb7f8f1a57859a24fc8e4966d6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/498080
Commit-Queue: Alexander Aprelev <aam@google.com>
Auto-Submit: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Fixes https://github.com/dart-lang/sdk/issues/54557
The generic type in JSExportedDartFunction corresponds to the
static type of the function it wrapped, whereas for JSFunction,
it's purely a descriptor of the JS function.
When calling JSExportedDartFunction, a cast is now introduced
to cast it to T.
When calling isA, the type in JSExportedDartFunction is passed
along to check that the value that is wrapped is that function
type. Because the T in JSFunction is descriptive, e.g.
isA<JSFunction<int Function()>>() does no such check.
____
Also cleans up:
- isA<JSTypedArray>() logic to use intrinsic functions
- some expectation files to be consistent for both dart2js and ddc.
CoreLibraryReviewExempt: Backend-specific library with needed reviews.
Change-Id: I1a55c4386e416fa4ccabe06ac5051f41c2e2e95a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/496820
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
This is a re-land of 152cc24, which has been reverted in 3f9ae7. Unlike
the original change, this doesn't alter the `dart:_wasm` library.
We can revisit an API split to remove `js_interop` APIs there once the
standalone target has progressed further.
Original change's description:
> [dart2wasm] Split patch files by whether they use JS interop
>
> The eventual goal of the `dart2wasm_standalone` platform is to not rely
> on a JavaScript environment, which requires rewriting everything that
> currently relies on `js_interop` or `JS()` helpers.
>
> Since most of the patches are still written in Dart and we don't want
> to duplicate that code for the standalone target, this splits patch
> files by whether they rely on JS-interop or not. The main entrypoint
> for each patch (e.g. `lib/_internal/wasm/lib/core_patch.dart`) no
> longer relies on JS-interop and can safely be used in the standalone
> target. Part files that previously needed to use JS-interop have been
> moved into separate patches now, which allows us to migrate them
> incrementally.
>
> In some cases, it was easier to add new patch files:
>
> - Similar to the split between `boxed_int` and the `toString` helper
> patch, we now have the same for `boxed_double`.
> - The functionality to copy from JS typed data wrappers into Dart typed
> lists wouldn't work with standalone, so I've moved it into a separate
> method we can patch to be a noop.
> - `dart:_wasm` exposes APIs to convert between `JSAny` and `externref`.
> This is part of a public API, but I had to move those declarations
> into a patch file because they wouldn't work with standalone.
> Arguably, a separate library (`dart:_wasm_js_interop`?) would be
> cleaner but it might be fine as long as `dart:_wasm` is experimental?
>
> For now, new patch files relying on JS interop are also applied to the
> standalone target. They are marked with a comment indicating that they
> need to be migrated though.
Cq-Include-Trybots: luci.dart.try:flutter-analyze-try
Change-Id: I98a628f96cba7e0f0af7e86e058cda43c2c73898
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/495302
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
To work properly with anonymous methods, the private field promotion
logic in flow analysis will have to be updated so that it understands
that `this` refers to a different object inside of an anonymous
method.
This CL adds new language tests to validate that this logic has been
properly updated.
Change-Id: I4ad2c289c5b39bb7397e68eff74324226a6a6964
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/496720
Commit-Queue: Paul Berry <paulberry@google.com>
Auto-Submit: Paul Berry <paulberry@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
This CL adds an implementation of anonymous `=>` methods in the CFE
which is sufficiently complete to handle the existing test cases in
language/anonymous_methods/expression.
Coverage is handled by adding magic comments to ignore the fact that new
code is not covered by existing testcases. This will be settled in a
separate CL.
To keep the failures visible, the failures in configurations
dart2js-hostasserts-linux-d8-try, dart2js-linux-chrome-try,
dart2js-minified-linux-d8-try, and ddc-linux-chrome-try have not been
approved. It seems likely to me that those are bugs in dart2js and in
DDC.
Change-Id: Ia70fedd4de6166d6a3bf8a108f49728b6e16c9f6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/494440
Commit-Queue: Erik Ernst <eernst@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This reduces essentials main module around -0.4% and possibly
opens up for changes in the inlining (specifically to possibly
not force-inline all initializers anymore)
This shrinks the amount of information
* initializer result values
* the body parameters
* the allocator needs to forward less from initializer to body
We do that by analyzing constructor parameters to see
which parameters are needed for the constructor
Change-Id: I967fa4102ea6e9d498ff07aedabc368b038e1085
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/496341
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
This stops the practice of removing the const modifier from const constructors with a body. Since primary constructor introduces more complex scenarios of this problem space, retaining the constness seems to have better results in terms of cascading errors. In particular, not reporting that a non-const constructor cannot be invoked when it is actual a const (alas erroneous) constructor.
Change-Id: I33b3982ec0fce89946f8700f98bf08161d930d36
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/494120
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This reverts commit 152cc247e0.
Reason for revert: Broken web_ui analysis (see flutter-analyze)
Original change's description:
> [dart2wasm] Split patch files by whether they use JS interop
>
> The eventual goal of the `dart2wasm_standalone` platform is to not rely
> on a JavaScript environment, which requires rewriting everything that
> currently relies on `js_interop` or `JS()` helpers.
>
> Since most of the patches are still written in Dart and we don't want
> to duplicate that code for the standalone target, this splits patch
> files by whether they rely on JS-interop or not. The main entrypoint
> for each patch (e.g. `lib/_internal/wasm/lib/core_patch.dart`) no
> longer relies on JS-interop and can safely be used in the standalone
> target. Part files that previously needed to use JS-interop have been
> moved into separate patches now, which allows us to migrate them
> incrementally.
>
> In some cases, it was easier to add new patch files:
>
> - Similar to the split between `boxed_int` and the `toString` helper
> patch, we now have the same for `boxed_double`.
> - The functionality to copy from JS typed data wrappers into Dart typed
> lists wouldn't work with standalone, so I've moved it into a separate
> method we can patch to be a noop.
> - `dart:_wasm` exposes APIs to convert between `JSAny` and `externref`.
> This is part of a public API, but I had to move those declarations
> into a patch file because they wouldn't work with standalone.
> Arguably, a separate library (`dart:_wasm_js_interop`?) would be
> cleaner but it might be fine as long as `dart:_wasm` is experimental?
>
> For now, new patch files relying on JS interop are also applied to the
> standalone target. They are marked with a comment indicating that they
> need to be migrated though.
>
> Change-Id: I583f23f6cc1a3fc7332962292d69f3a7b0327409
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/489660
> Reviewed-by: Slava Egorov <vegorov@google.com>
> Reviewed-by: Martin Kustermann <kustermann@google.com>
> Commit-Queue: Martin Kustermann <kustermann@google.com>
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Change-Id: I21428bdabcabdbdd07f3453384bb31154083c8aa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/494920
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
Yesterday I discovered some code in the front end type inference
engine that I didn't expect: logic that added constraints to type
inference based on the result of applying type coercions. To figure
out why it was necessary, I disabled it and ran the code through
trybots. It turns out that it's needed to prevent the following
issues:
- https://github.com/dart-lang/sdk/issues/33298
- https://github.com/dart-lang/sdk/issues/56666
Fortunately, we had regression tests for these issues:
- `pkg/front_end/testcases/general/bug33298.dart`
- `pkg/front_end/testcases/general/issue56666.dart`
Unfortunately, those regression tests are front-end specific, meaning
we didn't have any coverage for the analyzer.
This CL adds coverage for the analyzer by replicating the regression
tests in `tests/language`.
Change-Id: Ia53b3c898549e991d6685a414d177a466a6a6964
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/494563
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
The eventual goal of the `dart2wasm_standalone` platform is to not rely
on a JavaScript environment, which requires rewriting everything that
currently relies on `js_interop` or `JS()` helpers.
Since most of the patches are still written in Dart and we don't want
to duplicate that code for the standalone target, this splits patch
files by whether they rely on JS-interop or not. The main entrypoint
for each patch (e.g. `lib/_internal/wasm/lib/core_patch.dart`) no
longer relies on JS-interop and can safely be used in the standalone
target. Part files that previously needed to use JS-interop have been
moved into separate patches now, which allows us to migrate them
incrementally.
In some cases, it was easier to add new patch files:
- Similar to the split between `boxed_int` and the `toString` helper
patch, we now have the same for `boxed_double`.
- The functionality to copy from JS typed data wrappers into Dart typed
lists wouldn't work with standalone, so I've moved it into a separate
method we can patch to be a noop.
- `dart:_wasm` exposes APIs to convert between `JSAny` and `externref`.
This is part of a public API, but I had to move those declarations
into a patch file because they wouldn't work with standalone.
Arguably, a separate library (`dart:_wasm_js_interop`?) would be
cleaner but it might be fine as long as `dart:_wasm` is experimental?
For now, new patch files relying on JS interop are also applied to the
standalone target. They are marked with a comment indicating that they
need to be migrated though.
Change-Id: I583f23f6cc1a3fc7332962292d69f3a7b0327409
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/489660
Reviewed-by: Slava Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
This CL changes the flow analysis slightly such that the analyzer is
able to handle a `break;`, `break L;`, `continue;`, or `continue L;`
that occurs in the body of an anonymous method. It adds a test for a few
situations where this feature is used.
Change-Id: I5b065a6ad96e346502fd071d1547ccd143f37e80
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/491800
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
Also updates a few tests due to changes in how createEvent
can be used. That browser API has been deprecated for a long
time, but only recently did Chrome remove support for
PopStateEvent through that API. So, instead to retain the
original intent of the test, confuses are added after
constructing the event to check that type tests work correctly.
A few other tests are modified to remove code that depends on
createEvent, either through eventType or supported members.
See the Chrome bug for more details on the removal:
https://issues.chromium.org/issues/41228793#comment38
Change-Id: Id55a215583221de3ccdbbeff16a2e17e9e35fb0b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/494160
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Auto-Submit: Srujan Gaddam <srujzs@google.com>
Martin Kustermann