Update the format of the shape keys to better match the format used in
the dart:_rti library. This change applies to the current runtime type
system as well.
Change-Id: I87d2af2aaf2b9dbe012fae60a64718d264a3a18c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/295721
Reviewed-by: Mayank Patke <fishythefish@google.com>
Reviewed-by: Mark Zhou <markzipan@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Also includes https://dart-review.googlesource.com/c/sdk/+/302680
that was reverted because of adding extre diagnostics for Flutter.
Change-Id: I4cf7cedfcb67a5af226e609d279551fea0b0dee1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/302844
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
These tests are flaky or timing out on the stable DDC configurations.
This change adds skips for the canary configurations to avoid crashing
the infra when too many tests that timeout are attempted to be
deflaked.
When the canary mode stabilizes we should manually mark all these
tests as flaky if they are still not passing on the stable DDC
configurations.
Issue: https://github.com/dart-lang/sdk/issues/50666
Change-Id: I9b1cb8fe466624480767fea05610331bf0f4ed87
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/302843
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
When a post-feature library implements a pre-feature library declaration that has a final core library class as a super declaration, it should not produce a base/final/sealed transitivity error. Subclasses of a base core library class will still emit this error.
Otherwise, if base/sealed/final is omitted in a non-implement case, we want to report these errors.
Bug: https://github.com/dart-lang/sdk/issues/52315
Change-Id: Icdd4f63f69b061be5eabc7fd30b703d0358018a7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/302365
Commit-Queue: Kallen Tu <kallentu@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
With one exception (noted below), the shared analysis logic uses the
convention that the expressions passed to flow analysis are the
original (pre-lowered) expressions, whereas the expressions passed to
flow analysis by the CFE are the lowered expressions. This difference
caused two problems:
- If a boolean expression appeared on the right hand side of a pattern
assignment or pattern variable declaration, and it was lowered, the
flow analysis implications of that boolean expression would be lost.
- If a boolean expression appeared in a `when` clause, and it was
lowered, the flow analysis implications of that boolean expression
would be lost. Exception: for switch statements, the shared analysis
logic has been passing lowered expressions to flow analysis, so this
problem didn't occur for `when` clauses in switch statements.
Notably, when compiling for the VM, the CFE lowers expressions like
`x != null` to something more like `!(x == null)`.
Fortunately, the first of these two situations shouldn't cause
problems very often, since typically if the right hand side of an
assignment or variable declaration is a boolean expression, there is
no need for the left hand side to involve patterns.
As for the second of these two situations, it's also not too likely to
cause problems, since typically null checks occur inside patterns
rather than in `when` clauses.
As a short term fix, we remove the exception noted above, and we
account for the difference in conventions by adding a call to
`FlowAnalysis.forwardExpression` to the CFE's implementation of
`dispatchExpression`, so that when transitioning between CFE logic and
shared logic, flow analysis will be informed how to match up the
lowered expressions to their pre-lowered counterparts.
Longer term, I would like to switch everything to the convention of
using the original (pre-lowered) expressions; this will bring the
analyzer and CFE into better alignment with each other and should
eliminate a class of subtle bugs. This long term goal is tracked in
https://github.com/dart-lang/sdk/issues/52189.
Fixes#52183.
Fixes#52241.
Bug: https://github.com/dart-lang/sdk/issues/52183, https://github.com/dart-lang/sdk/issues/52241.
Change-Id: I2449ce34c54325603bc2730d1660a7cfc7d79aec
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/298840
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This behaviour should only happen when a post-feature library implements
a pre-feature library declaration that has a final/base core library class as a super declaration.
Bug: https://github.com/dart-lang/sdk/issues/52115
Change-Id: If42129ba3ba7e337cc6ffc21604c6d0f2976344c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/301503
Reviewed-by: Nate Bosch <nbosch@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
We've changed the semantics for these members using dart:js_interop
so that not passing in optionals on the Dart side is equivalent to
not passing in optionals on the JS side. This CL makes that consistent
with package:js as well.
Modifies CHANGELOG to announce breaking change.
Change-Id: Ic5c33c9c797983a72edec9bc59f60fc1f29240b4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/300400
Reviewed-by: Joshua Litt <joshualitt@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Disallows tear-offs for all interop members when using
dart:js_interop, and disallow tear-offs of @staticInterop and
extension external members. Creates tear-off indexes in
InlineExtensionIndex to keep track of tear-off methods that
the CFE generates.
Modifies the CHANGELOG to communicate the breaking change.
Change-Id: I900fdfd6ee6b198f2f34e9d9fd5f3d9c964680e3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/299800
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Joshua Litt <joshualitt@google.com>
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>
