Allows the following semantics:
- If the disable flag is passed, never check
- If we're in non-sound mode, never check to avoid a breaking
change (this was the behavior before)
- If the enable flag was passed and we're in sound mode,
always check
- If we're in sound mode and with >= -03, don't check
Discussion in https://github.com/dart-lang/sdk/issues/50710
Change-Id: If83aaebb2745e4c8bcaa3f5a38ff41d79a869b8b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/289451
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
According to the spec, the expression inside a relational pattern is
`bitwiseOrExpression`. We were only allowing `shiftExpression`.
Bug: https://github.com/dart-lang/sdk/issues/50035
Change-Id: Ie1a5746f1060b84e6e1b856a622e89db698b4684
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/292285
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
The implementations are doing the right thing, but the tests are
slightly off:
- The CFE doesn't report unreachable case warnings because they are
non-fatal warnings, so remove those expectations. (But analyzer does,
so continue to check that analyzer reports them.)
- The CFE reports shared case variable errors at a different location.
Change-Id: I7143a7705d3c8879fb91e5fdb8df8599bfb96165
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/292520
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Just corner cases that occurred to me while specifying the
implementation. There's probably already front end tests for it too, but
I like the idea of having some language coverage as well.
Change-Id: I158f274483799c3ccb29c32f0e7c5c42d31f327f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/291962
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Eventually, these hints should probably be moved over to warnings. But
for now, this makes it possible to write static error language tests
that validate that analyzer produces unreachable case warnings/hints
where expected.
Also updated the patterns/ and switch/ tests now that those errors must
be expected by the test.
Change-Id: If1fb92602c4bde2819b9eec73598033009054947
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/291967
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Bob Nystrom <rnystrom@google.com>
The precedence-based pattern parser can understand a unary pattern
inside another unary pattern (e.g. `_ as int as num`) or a relational
pattern inside a unary pattern (e.g. `> 1?`), but the specification
prohibits these constructions because they're difficult to read and
not very useful.
This change updates the implementation to match the spec, by producing
the appropriate error. The offset and length of the error cover the
inner pattern, so it should be easy to construct an analysis server
quick fix that inserts the necessary parentheses.
Bug: https://github.com/dart-lang/sdk/issues/50035
Change-Id: I33e74d6d1f863e7162851d26fefbacd4fd17277c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/292120
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The logic for parsing types has special disambiguation rules for
deciding whether a trailing `?` should be included in the type, based
on what token(s) follow the `?`. In the case where the token that
follows the `?` is `when`, we need to look further ahead to
disambiguate, to distinguish `PATTERN as T? when guard` from something
like `EXPRESSION is T ? when : otherwise`.
(Note: an alternative implementation would be to disambiguate based on
whether we're parsing a pattern or an expression. But in the future I
want to move toward an architecture where expression parsing and
pattern parsing are combined, so that if the parser makes the wrong
decision about whether it's looking at a pattern or an expression,
error recovery will do a better job. So I'm disambiguating based
solely on what follows the `?`.)
Bug: https://github.com/dart-lang/sdk/issues/50035
Change-Id: Idbc780b7b54fecc7fd01cae868c34771564dd804
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/292282
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
It is still an error to have duplicate keys.
Change-Id: Id86fa7b50c3620540f4bef0399f5f70316848662
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/292125
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Jake Macdonald <jakemac@google.com>
Commit-Queue: Bob Nystrom <rnystrom@google.com>
This is another reland of 4f8333e80e.
Third time is the charm.
CoreLibraryReviewExempt: Reland of accepted CL.
Change-Id: I4ea8326af91c168b044d252162571d3fe697e4b0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/289826
Commit-Queue: Lasse Nielsen <lrn@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
The listener API for variable patterns is split into three separate
functions, to handle the three separate behaviors:
- `handleAssignedVariablePattern` for variable names appearing in an
assignment context (these assign to an existing variable upon a
successful match).
- `handleDeclaredVariablePattern` for variable declarations appearing
in a declaration or matching context (these cause a new variable
name to come into scope).
- `handleWildcardPattern` for wildcards in any context (these don't
capture the matched value).
Also, responsibility is shifted to the parser for reporting the
following error conditions:
- VariablePatternKeywordInDeclarationContext (e.g.
`var (var x) = ...;`)
- PatternAssignmentDeclaresVariable (e.g. `[x, var y] = ...;`)
Previously these errors were detected by the implementations, and
weren't fully covering all possible error scenarios.
In the case of VariablePatternKeywordInDeclarationContext, the
listener method `handleDeclaredVariablePattern` is called instead of
`handleAssignedVariablePattern`. This ensures that no tokens are
dropped from the analyzer AST. The CFE uses the `inAssignmentPattern`
argument of `handleDeclaredVariablePattern` to distinguish this error
recovery case from a legitimate declared variable pattern.
Fixes#51868.
Bug: https://github.com/dart-lang/sdk/issues/51868
Change-Id: I28ec679b73d64033166721c6460be35f15e23171
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/291583
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
On the web, some inputs to `Duration` would make -0.0
occur in positions where the code assumed an integer
with a reasonable `toString`.
Adds `+ 0` and using `0 - x` instead of `-x` to
avoid ever ending up with a `-0.0`.
Fixes#51584
CoreLibraryReviewExempt: Bugfix, no API changes.
Change-Id: Idecfaf049f2ae5677792387ce24e95add99596cb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/291280
Commit-Queue: Nate Bosch <nbosch@google.com>
Auto-Submit: Lasse Nielsen <lrn@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Added error messages for when users try to use invalid mixins + a language test that tests that (and tests in each of the front ends).
Removed the tokens from the parser listeners.
Removed all behaviours and error reporting related to these invalid mixins.
Change-Id: I558595826dae7e2c176bd1929e97caa2335c167c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/290614
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Change-Id: I2cc53a7f41721fd146051502ee2f9e102656ed61
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/291968
Auto-Submit: Leaf Petersen <leafp@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
This is a reland of commit 608934e330
Can be landed when Flutter with https://github.com/flutter/flutter/pull/123211
has been rolled into internal repository.
Original change's description:
> Reland "Add class modifiers to `dart:convert`."
>
> This is a reland of commit b2f4cf3e01
>
> Commented out deprecation for now.
>
> Original change's description:
> > Add class modifiers to `dart:convert`.
> >
> > The usual approach:
> > Pure interfaces marked `interface`.
> > Pure implementation classes marked `final`.
> > Base classes marked `base` or nothing, and `mixin class` if reasonable.
> > Combined X/XBase/XMixin where possible.
> >
> > CoreLibraryReviewExempt: Aske is away
> > Change-Id: I927f9bd488fb385ff9c17c8fc94920a1f5076347
> > Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/289200
> > Reviewed-by: Stephen Adams <sra@google.com>
> > Reviewed-by: Slava Egorov <vegorov@google.com>
> > Reviewed-by: Nate Bosch <nbosch@google.com>
> > Commit-Queue: Lasse Nielsen <lrn@google.com>
>
> CoreLibraryReviewExempt: Approved in original.
> Change-Id: I1bc14f99b742567e2634dcfcbc52f332dbcc5364
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/290521
> Reviewed-by: Nate Bosch <nbosch@google.com>
> Commit-Queue: Lasse Nielsen <lrn@google.com>
CoreLibraryReviewExempt: Approved in original.
Change-Id: If157e1ef2339d7a06e99a1e402f2f8ac93550b83
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/290960
Reviewed-by: Nate Bosch <nbosch@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
Then when using a final class in an on clause outside of its library, we don't produce a base/final subtype error.
Change-Id: Ib96efefb04639496daeee0de98c5711e73709ac5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/291591
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
To match up with analyzer behaviour, we want to only report subtype errors
on the first erroneous subtype instead of every subtype down the tree.
Change-Id: Ifb93ef39498e93d075a475fff8939017b563414e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/291344
Commit-Queue: Kallen Tu <kallentu@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
SendPort/ReceivePort/RawReceivePort become interface classes as there
are existing implementations of those classes (e.g. `package:isolate`
has `Multiplex*Port` classes those).
Since Capability is implemented by SendPort it also becomes an interface
class.
All remaining classes become final - we can always be less restrictive
in the future if needed.
It seems good practice to also add modifiers to private classes (one
reason is that private classes can be exported via e.g. typdef).
TEST=ci
CoreLibraryReviewExempt: No API changes except for modifiers, vm-only library.
Change-Id: I5edf04624a5dc588ac5f49bb898f29b5bc121d5f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/288201
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Also, when using a final class in an on clause outside of its library, we don't produce a base/final subtype error.
Change-Id: I6600bc136ca37e98f9698c604214a6c565d6a9af
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/290263
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
Decorate Zone, Future, Completer, Timer and Stream with newly-introduced pragma to make sure that message verification stops earlier, produces shorter retaining path for the user.
BUG=https://github.com/dart-lang/sdk/issues/51722
TEST=send_unsupported_objects_test,isolate_exit_unsendable_test.dart
CoreLibraryReviewExempt: vm-specific pragmas
Change-Id: I499eea542d228ac9cf0797a682664f93f360dc80
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/289027
Commit-Queue: Alexander Aprelev <aam@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
base mixins and base mixin classes.
Change-Id: Idfe7576f38382c5e9a0ff968aae00f48990e1d38
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/290351
Commit-Queue: Leaf Petersen <leafp@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
Disallow using final classes on on-clauses outside of its library.
Update tests to show this behaviour. (Or at least in a state where I can test out the implementation)
Change-Id: I74306c873dbd047c6b94d8e8e75c215562dd9483
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/290915
Commit-Queue: Kallen Tu <kallentu@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
I've also added some runtime checks to
`tests/language/patterns/object_pattern_inference_test.dart` to verify
that the object patterns match when they should match and don't match
when they shouldn't; this helps verify that not only has the front end
inferred the correct type for the object patterns, but it has also
stored the correct type in the kernel representation.
Fixes#51795.
Bug: https://github.com/dart-lang/sdk/issues/51795
Change-Id: I73ce43e440db50d9942deb4a1eb4ee68a5c23142
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/290900
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Change-Id: I5e208edc53543de8d11aa6e81072ad7f61a23d52
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/290913
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
CoreLibraryReviewExempt: Minor refactor of web only library.
Change-Id: I7afc4a00501ac12c1aa0248305001a978f2e9f8f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/288641
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Joshua Litt <joshualitt@google.com>
Test currently fails on both DDC and dart2js
Bug: 51527
Change-Id: I229d5c9ba518d3323f98312f13740711523439e9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/290350
Reviewed-by: Mark Zhou <markzipan@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
This code handles simple cases. Still TBD:
- Object patterns that refer to typedefs
- Object patterns that refer to classes with f-bounded polymorphism
- Inference of `dynamic` when there is no bound
Bug: https://github.com/dart-lang/sdk/issues/51795
Change-Id: I00acae6ba111f7b170650cfeffbfd2aaf7f71e42
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/290347
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Our previous visitor was manually implemented. Extending the recursive visitor instead helps us be more robust to future CFE updates.
Fixes#51802
Change-Id: I9efebdf28fdf9146c2d1f948e01363a77807aa16
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/290280
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Mark Zhou <markzipan@google.com>
This is a reland of commit b2f4cf3e01
Commented out deprecation for now.
Original change's description:
> Add class modifiers to `dart:convert`.
>
> The usual approach:
> Pure interfaces marked `interface`.
> Pure implementation classes marked `final`.
> Base classes marked `base` or nothing, and `mixin class` if reasonable.
> Combined X/XBase/XMixin where possible.
>
> CoreLibraryReviewExempt: Aske is away
> Change-Id: I927f9bd488fb385ff9c17c8fc94920a1f5076347
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/289200
> Reviewed-by: Stephen Adams <sra@google.com>
> Reviewed-by: Slava Egorov <vegorov@google.com>
> Reviewed-by: Nate Bosch <nbosch@google.com>
> Commit-Queue: Lasse Nielsen <lrn@google.com>
CoreLibraryReviewExempt: Approved in original.
Change-Id: I1bc14f99b742567e2634dcfcbc52f332dbcc5364
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/290521
Reviewed-by: Nate Bosch <nbosch@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
