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>
Report dedicated diagnostics for mixin classes that use a `with` clause
and for mixin application classes that use multiple mixins, instead of
folding both cases into `mixinClassDeclarationExtendsNotObject`.
This makes the reported error match the actual invalid construct. A
`mixin class` with a `with` clause does not have the same problem as a
`mixin class` that extends a non-`Object` superclass, and a mixin
application with multiple mixins is a separate restriction again.
Update the error verifier, diagnostic definitions, messages, and fix
status entries to use the new codes. Also guard `RemoveExtendsClause` so
it only offers a fix when an actual extends clause is present, avoiding
a bogus fix for diagnostics that are now reported on `with` clauses
instead.
Consolidate the diagnostic tests under a single mixin class declaration
test file and update expectations to use the more precise error codes.
The original impetus for this change was a crash in RemoveExtendsClause
quick fix.
Change-Id: I937276f37deb293ca1fecab3ff838ace45af2ec4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/493865
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
When a class type parameter is referenced from a static member, the
analyzer could still instantiate it as an ordinary type parameter during
resolution and summary building. That produced inconsistent invalid
states, led to follow-on type errors, and could crash later stages that
expected a real type or a consistently invalid one.
Teach `ScopeContext` to track whether resolution is inside a static
member and use that information when instantiating type parameters. If
the referenced type parameter belongs to the enclosing instance context,
resolve it to `InvalidType` instead.
Route both `NamedTypeResolver` and `reference_resolver` through this
shared helper so fields, methods, and other named type paths handle
static references consistently. This keeps the original
`TYPE_PARAMETER_REFERENCED_BY_STATIC` diagnostic while preventing
spurious assignment and return-type errors from cascading afterward.
Bug: https://github.com/dart-lang/sdk/issues/60745
Change-Id: Ib9e685b967de5baa8a26b542be630c9fb0d6a96b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/494040
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
1. The redirect credential leak was caused because the arguments to `shouldCopyHeaderOnRedirect` were passed in the wrong order
2. The HTTP request smuggling was caused by incorrect identification of chunked transfer encoding.
Closes https://github.com/dart-lang/sdk/pull/63133
GitOrigin-RevId: 1e6189fd7cd7b0360566f01d02c82a71de5d0f0a
Change-Id: I7c76615d12b6dac8888c1cdc3a6cab46199f6b0a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/493600
Commit-Queue: Brian Quinlan <bquinlan@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
These tests cover the behaviors mentioned in
https://github.com/dart-lang/language/issues/4672.
Long term, I'm not certain whether these are the behaviors we
want. But considering that these are the behaviors we have, it seems
reasonable to test them to avoid regressions.
Paves the way for a follow-up CL that will refactor some of the
analyzer and front end logic that handles yield statements.
Change-Id: I6af8eb67dac588d90ed95e2536184c4a6a6a6964
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/491706
Reviewed-by: Erik Ernst <eernst@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This update the position used for reporting a mixin class primary constructor with a primary constructor by declaration with initializers or an explicit body. Since mixin classes can have simple constructors, it makes more sense to report the error on the offending syntax than on the primary constructor itself.
The CL also updates the offset used for field initializers to the field name rather than the `=`. This align the offset with what is used for property sets.
Change-Id: Id5ccd55536b2c3b9d9336d2854772c1bcc5a175a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/490800
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
These tests use `external` modifier on constructors, and dart2js/ddc only supports external on constructors marked as JS-interop and therefore reports compile-time errors for these tests.
Change-Id: I7f55086170b06d2b31bda8c1916780622502df41
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/490540
Reviewed-by: Erik Ernst <eernst@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
mohammadmseet-hue