Mark in status file instead of with test workflow so that test.py is
fully green and all current triaged failures are marked in status file.
Bug: https://github.com/dart-lang/sdk/issues/39487
Change-Id: Ib0729a9ee68d7f0e0f8a9ad30238e537467f8426
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/302322
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Auto-Submit: Daco Harkes <dacoharkes@google.com>
Checks an interface's supertypes for final classes and produces an error if the implementing bypasses a legacy library.
This behaviour should only happen when a post-feature library implements
a pre-feature library declaration that has a final class as a super
declaration.
Similar error to https://dart-review.googlesource.com/c/sdk/+/298320
Bug: https://github.com/dart-lang/sdk/issues/52078
Change-Id: Ie16edb2b231957dad7502fdab3d5faba93bc6773
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/300861
Commit-Queue: Kallen Tu <kallentu@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
In https://dart-review.googlesource.com/c/sdk/+/299400, the parser was
adjusted so that it no longer accepts `when` and `as` as the names for
variable patterns in cases where there is a possible ambiguity
(e.g. `int when` is not accepted as a pattern because `int` is a
legitimate pattern, therefore `when` could introduce a guard
clause). This change further prohibits `when` and `as` from being the
names of variable patterns or identifier patterns even in the case
where there is no ambiguity. This is in line with the discussion at
https://github.com/dart-lang/sdk/issues/52199#issuecomment-1526297771,
and the spec change at
https://github.com/dart-lang/language/pull/3033.
Three new error codes are introduced, to cover the three circumstances
in which `when` or `as` might be used illegally: in a declared
variable pattern, in an assigned variable pattern, or in an identifier
pattern. I've also added analyzer tests to ensure that the parser
recovers from these errors nicely. Unfortunately, nice error recovery
is only feasible in the non-ambiguous cases.
I've also updated the language test expectations in
`tests/language/patterns/version_2_32_changes_error_test.dart` to
reflect the new error messages, and added a few more examples of uses
of `when` and `as` that are still permitted.
Fixes#52260.
Bug: https://github.com/dart-lang/sdk/issues/52260
Change-Id: I229f627aa639659c30b83c74895759207da279f7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/301482
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
In DDC the types [num], [int], [double], [String], and [bool] used in
bounds caused an "optimization" in type tests that was incorrect when
passing a subtype as the type argument.
Issue: https://github.com/dart-lang/sdk/issues/52243
Change-Id: I0ae8d21c907cd923d62dbae257085545840a8cdf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/301140
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Our helper function to detect whether a null-assertion was required
didn't include a case to check for record types.
The null-assertion flag is likely to go away soon, since it's
only valuable for mixed applications.
Fixes#52276
Change-Id: Ief4515b8c3eaae5343012da4220e6051bb5a2f19
Fixed: 52276
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/301680
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Nate Biggs <natebiggs@google.com>
https://dart-review.googlesource.com/c/sdk/+/300600 migrated some tests
to use a new TEST_COMPILATION_DIR flag, but this test was incorrectly
migrated. The test was failing on the legacy bots.
Change-Id: Iac6fa3e946dc29d840068813123359262fe59474
TEST=Local testing and CI
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/301220
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Liam Appelbe <liama@google.com>
Extend test_runner VMOptions support with an ability to specify
paths relative to temporary compilation directory.
// VMOptions=--foo=$TEST_COMPILATION_DIR/foo.file
The same directory will also be passed as an environment variable
to execution command.
Migrate most of the tests which used to write stuff into the SDK
root to use this feature. I am leaving vm/dart/causal/* tests
unmigrated because migrating requires time consuming manual
update of expectations (which encode raw line numbers). I have
a follow up CL which changes how these tests are written which
will make migration trivial.
Change-Id: Id53008be66de8ff18623efac27ff15750f407749
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/300600
Reviewed-by: William Hesse <whesse@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
This reverts commit 4919729f00.
This CL also adds back in logic to handle older package:js versions to avoid
failures in our static checking. It also supports dart:js_interop's @JS
annotation since it can now be used for @staticInterop classes.
CoreLibraryReviewExempt: Reland of backend-specific library changes.
Change-Id: I104653a9a6b2593f6bab658808287e2074c18550
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/294130
Reviewed-by: Joshua Litt <joshualitt@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Also update the test name to follow test naming conventions (tests
with error expectations are named `*_error_test.dart`), and add a
copyright notice and test description.
Bug: https://github.com/dart-lang/sdk/issues/52202
Change-Id: I762dcbf6ebd02190250ccdd9767e6db29cac1d61
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/300322
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Ensure there are tests for all the different code paths that
throw `NoSuchMethodError` when making some kind of dynamic invocation.
Add tests to cover the name descriptors that appear as well. Some are
confusing and in need of improvement.
Null values in particular will cause a crash before correctly throwing
a `NoSuchMethodError`.
Change-Id: I54bbb91214e0d333b1a99abe455c8ff1a4df6cb9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/297182
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Mark Zhou <markzipan@google.com>
This change fixes parsing of case clauses such as:
case foo when !flag:
Constructions like this require some lookahead in order to parse
correctly, because the token `when` is valid both as an identifier and
as a part of the grammar for a case clause. Therefore, at the time
`foo` is encountered, the parser must decide whether it is looking at
a variable pattern (`foo when`, where `when` is the name of the
variable) or an identifier pattern (`foo`, where `when` begins the
case's guard clause). Previous to this fix, the algorithm for
disambiguating these two choices was as follows:
- If the token sequence starting at `foo` looked like a type, and the
token that follows was an identifier, the parser assumed it was
looking at a variable pattern with a type; otherwise it assumed it
was looking at an identifier pattern.
- EXCEPT that if the token that followed the supposed type was `when`
or `as` (both of which are valid identifiers), then it probed
further:
- If the token that followed `when` or `as` was a token that could
legitimately follow a pattern, then it assumed that it was looking
at a variable pattern with a type. (The tokens that could
legitimately follow a pattern are `,`, `:`, `||`, `&&`, `)`, `}`,
`]`, `as`, `when`, `?`, `!`).
- Otherwise it assumed that it was looking at an identifier pattern.
This didn't fully disambiguate, because the third bullet didn't
account for the fact that the tokens `as`, `when`, and `!` could
_either_ legitimately follow a pattern _or_ legitimately begin an
expression (or, in the case of `when`, a type), therefore constructs
like the following were incorrectly parsed:
- `case foo when as:` (where `as` is a local boolean variable)
- `case foo when when:` (where `when` is a local boolean variable)
- `case foo when !flag:` (where `flag` is a local boolean variable)
- `case foo as when:` (where `when` is the name of a type)
The solution is to simplify the disambiguation logic so that if if the
token that follows the supposed type is `when` or `as`, then the
parser assumes that it's looking at an identifier pattern, _not_ a
typed variable pattern.
The consequence of this is that the above four constructions are
parsed correctly; however it is no longer possible for a typed
variable pattern to name a variable `when` or `as`.
For consistency we would like to prohibit _any_ variable pattern from
naming a variable `when` or `as`, however to keep this change as small
as possible (and reduce the risk involved in a possible cherry-pick)
that will be postponed until a later CL.
Fixes#52199.
Bug: https://github.com/dart-lang/sdk/issues/52199
Change-Id: Ibab9b92f01e3e4020d7d64f1ff000a9b964a4564
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/299400
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Currently, dart:_js_types types are all typedefs in the web backends.
This leads to inconsistent semantics, since you can statically pass
Strings to JSString, for example. You cannot do this in dart2wasm.
In order to ensure consistent semantics, we reify these types using
a custom @staticInterop lowering. They all get erased to their
respective Dart type. When we have inline classes, these types
should be implemented using inline classes.
Note that Interceptor will not work for this use case. The reified
type of JS primitives are Dart types e.g. String, bool, and therefore
can not be casted to Interceptor.
In order to do this, the eraser is refactored and the JS backends use
shared erasure code to either erase/emit types.
Tests are added to make sure you need to go through a conversion or
cast to pass Dart objects to JS types.
CoreLibraryReviewExempt: Backend-specific internal library changes.
Change-Id: I5942be628102919ec167f094cfe10fced606363c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/295105
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Joshua Litt <joshualitt@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
These tests have been broken (and disabled) for a while. This pull-request fixes the tests and re-enables them.
Bug: #47052
Change-Id: Ib8c83959e5f00a2a5dc29959f87adbaa963385fe
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/296863
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
current library which itself extends a base declaration from another
library.
Change-Id: I3caf125de528d5c082c825c02055a114f732f385
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/298040
Commit-Queue: Leaf Petersen <leafp@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
This test was inadvertently broken when automatically migrated from a
multitest to a static error test.
The original intent of the test was to ensure that web compilers
reported compile-time errors on integer literals that couldn't be
represented as JS doubles. The migrated static error test doesn't have
any web expectations and thus doesn't get run on web compilers at all.
Instead, all it does is validate that the one non-web error in there is
reported.
This turns the test into a proper *web* static error test with the
web-specific test expectations in there. That ensures the test is run
on web compilers and validates that the web compilers produce those
expected errors.
Also removed the corresponding runtime test since it doesn't do
anything. There's no runtime behavior to test, and the static error
test also correctly validates that the *valid* integer literals do *not*
produce compile errors.
Removed the status file entries because they're no longer needed. Since
this is a static error test, the runtime platforms already skip it
implicitly.
Change-Id: I2776847e1acb88b1f761efb43e7bb528b27d0eee
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/297840
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Previously this step happened during `buildOutlineNodes`, but since
`buildOutlineNodes` happens in source order, this means that anonymous
mixins would only get their sealed and final attributes properly
inferred if they appeared *after* their immediate supertypes in source
order. By moving this step to `checkSupertypes`, we ensure that the
computation is correct regardless of source order, because
`checkSupertypes` happens in class hierarchy order.
Fixes#52048.
Bug: https://github.com/dart-lang/sdk/issues/52048
Change-Id: Ib9f1f3dafded88681a26f09e4d21dfd44e70dfd3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/297901
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This CL replaces https://dart-review.googlesource.com/c/sdk/+/296900
The `List` constructor is removed in Dart 3.0.
Some of the `@patch` implementations were not removed.
This is *high priority*. It seems the left-over `@patch factory List` constructor did not cause any errors, instead it *added* a constructor to `List` that can be used in web compiled code. Even if `List` doesn't have such a constructor in the SDK code proper.
The VM and analyzer will say the invocation is an error, but dart2js happily compiles it and runs.
(It used to be that patches couldn't add public members, that security seems to have been removed.)
Also removes code which tries to detect "the unnamed List constructor",
which is no longer a thing, and a number of invocations of the constructor, where it's not clear that the test is aware that the constructor no longer exists, and is not marked as `@dart=2.x` with x < 12.
TEST=ci
Change-Id: I4ffaf3ae2c4e75ca06e7ba0bf19187b6376f3888
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/297100
Reviewed-by: Brian Quinlan <bquinlan@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
The "@compile-error" comment is an old not-great way of defining static
error tests.
See: https://github.com/dart-lang/sdk/issues/45634
Change-Id: I3a41bb83767052abda1fdfc77e21bd1a83188482
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/296441
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Jake Macdonald <jakemac@google.com>
Commit-Queue: Bob Nystrom <rnystrom@google.com>
The "@compile-error" comment is an old not-great way of defining static
error tests.
See: https://github.com/dart-lang/sdk/issues/45634
Change-Id: I35d4a7c7ad09cb77ff379af036180794d8b6afbf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/296403
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Jake Macdonald <jakemac@google.com>
Commit-Queue: Bob Nystrom <rnystrom@google.com>
The "@compile-error" comment is an old not-great way of defining static
error tests.
See: https://github.com/dart-lang/sdk/issues/45634
Change-Id: Idf9012cb8c213b523d1c8bb827e530e0d2cf6609
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/296407
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Jake Macdonald <jakemac@google.com>
Commit-Queue: Bob Nystrom <rnystrom@google.com>
The "@compile-error" comment is an old not-great way of defining static
error tests.
See: https://github.com/dart-lang/sdk/issues/45634
Change-Id: I4c2840deffe5d790a22facebbcc8a02c1cb98020
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/296425
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Commit-Queue: Bob Nystrom <rnystrom@google.com>
State more explicitly that sealed classes are abstract and lead the
user to a better fix with the error message.
Bug: https://github.com/dart-lang/sdk/issues/52073
Change-Id: Id24c6cb187ee5497ca2819f930c48ff5aa8d07fc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/296025
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
The "@compile-error" comment is an old not-great way of defining static
error tests.
See: https://github.com/dart-lang/sdk/issues/45634
Change-Id: I3e10209e78e48893d2f2df7f8af7963d319efd9f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/296405
Reviewed-by: Jake Macdonald <jakemac@google.com>
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Auto-Submit: Bob Nystrom <rnystrom@google.com>
The "@compile-error" comment is an old not-great way of defining static
error tests.
See: https://github.com/dart-lang/sdk/issues/45634
Change-Id: I6218c6ea339b6c19c1495b1db9b2da3fe1654718
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/296440
Commit-Queue: Jake Macdonald <jakemac@google.com>
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Jake Macdonald <jakemac@google.com>
The "@compile-error" comment is an old not-great way of defining static
error tests.
Change-Id: I6564643302f66c5920b38d2269c160099322560b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/296421
Reviewed-by: Jake Macdonald <jakemac@google.com>
Commit-Queue: Jake Macdonald <jakemac@google.com>
Auto-Submit: Bob Nystrom <rnystrom@google.com>
