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>
The new version optimizes slightly better and much faster.
Change-Id: Icbd8cd01f149c609043572bdadd42be2afd6ac54
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/292301
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Aske Simon Christensen <askesc@google.com>
When patterns are enabled, the case expression is not an inferred
constant context.
Closes#51898
Change-Id: I6b5a68b8de587c53a329756b6ce7caa6b9235fef
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/292081
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This improves the precision of the Wasm types for Dart function types
in instance method signatures.
It could in principle also improve the precision of the receiver
parameter from the LUB of the representation types to the LUB of the
actual structs for the classes implementing the member. However,
if at a call site the receiver parameter type is more precise than the
representation type of the receiver, the call site will need to cast
the receiver to the more precise type. This gives rise to more casts
in practice than the ones saved inside the methods by the more precise
receiver parameter type. For this reason, the receiver parameter type
is kept at the LUB of the representation types of the classes
implementing the member.
This change is also a stepping stone towards not having `ClassInfo`
for the special Wasm types.
CoreLibraryReviewExempt: Only affects Wasm-specific libraries.
Change-Id: I81ca5aa1107f1c04ed7729a758e983698492a106
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/288400
Reviewed-by: Joshua Litt <joshualitt@google.com>
Commit-Queue: Aske Simon Christensen <askesc@google.com>
Use the `TrustedGetRuntimeType` interface to mark implementation
classes that have a `get runtimeType` that should be used for
reporting the types of instances in errors and `Record.runtimeType`.
Streamline the various more general `get runtimeType` implementations
by specializing them to the context. By explictly implementing
`Closure.runtimeType` we avoid the need to test for closures in the
'ordinary' object path. This should help the Flutter pattern of
testing `a.runtimeType == b.runtimeType`.
Change-Id: Ib49a6d89ff23e752beed8753aafceff40457433d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/291741
Reviewed-by: Mayank Patke <fishythefish@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
We encode line/column in a single 64-bit integer and derive offset from this using the lineStarts stored on the kernel Source object.
Saves 90-100MB of memory within the emitter phase on a large program. Most of that is from the smaller deserialized SourceLocation objects but some memory is also saved due to the smaller output size from the compact serial representation. The input to the emitter phase is ~14MB smaller (with the savings split across multiple codegen shards).
Change-Id: Ic71231fb43fc746293b6f6f77e0ee2c3b17742cf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/291900
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
In particular, this fixes some type tests involving records.
`(1, true) as FutureOr<(int, bool)>` was failing because the Rti for the
record literal was _Record_2 rather than +(int, bool). We want to avoid
constructing the full record Rti, so instead we can have the specializer
for FutureOr directly delegate to its union components.
Fixes: #51910
Change-Id: I3716882aab0a519ab35803d87fabe570b7e27655
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/292242
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Mayank Patke <fishythefish@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>
This allows for users to dismiss a notification without taking any action (something that VS Code / LSP allows for but this API did not).
Change-Id: Icf384008cfcfde6f150c63d3f2889e81e79d1dc1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/292080
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
- Mostly restores the pre-kernel behavior, except that actual arguments are not passed to the NoSuchMethodError.
- Instead of a vague error message, the call site whose target is missing is now part of the stack trace and the name/kind of the missing target is part of the exception message.
- If the missing target is on a branch not taken, things properly succeed.
TEST=ci
Bug: https://github.com/dart-lang/sdk/issues/37517
Bug: https://github.com/flutter/flutter/issues/122626
Change-Id: Ic3d5a386caa8d1627d8452a5601bc728ad519987
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/291055
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Change-Id: I068573a3534816b301fde8628d8f15f8c0286898
Tested: not really tested, should be a noop.
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/292022
Commit-Queue: Sigurd Meldgaard <sigurdm@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>
This forwards any `--packages` flag from before a dartdev command name to dartdev, so also eg. `dart --packages=... compile` will now work as expected.
And commands that don't take a --packages flag will complain (eg `dart --packages=... devtools`.
Change-Id: I0448b97aae394cb94541cfa087a6d28908e480e5
Tested: <Tested via pkg/dartdev/test/commands/run_test.dart>
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/292020
Reviewed-by: Jonas Jensen <jonasfj@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Sigurd Meldgaard <sigurdm@google.com>
This hack was needed to cover a short time period in 2020 where an
improvement to flow analysis had landed in master but hadn't yet
landed in the checked-in SDK that is used for presubmit checks. We
are long past needing it anymore.
Change-Id: I0d0cd3d4d9829cc4b0798a07feaac09bb4929f31
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/291841
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This file has seemingly been untracked in my checkout for more than a
year. Probably I forgot to add it in
468f939428.
Change-Id: I2d86616960bd4636a6b46c5c09c314261421ab89
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/292006
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@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>
This updates the checking order of the exhaustiveness algorithm to
process the sealed type on its own before checking the subtypes. This
has the benefit that for fields that fully covered by (a supertype of)
the sealed type itself, like a wildcard pattern, we avoid checking
each individual subtype.
For the exponential cases added in
https://dart-review.googlesource.com/c/sdk/+/291800
this avoids the exponential growth, bringing the number of checked
witness candidates from 837932 to 6 for the "subtype" test with n = 30 and from 12207032 to 12 for the "fields" test with n = 10.
The change also fixes a problem in the 'future_or_members.dart' caused by the non-null version of 'FutureOr<dynamic>' still being nullable. The old algorithm tried to use 'Object' as a witness canditate but filtered out 'FutureOr<dynamic>' because 'Object' wasn't a subtype if it. The new algorithm starts by using 'Object?' and therefore sees that 'FutureOr<dynamic>' exhausts it. This is an inherent problem in the modelling of StaticType and it should still be addressed.
Change-Id: Iaa5d5604afc4662fe1983d670638223eae5dbf6b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/291822
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: 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 flag is set when a variable declaration is moved earlier in
order to be available for subsequent code that couldn't contain
its declaration. For instance variables declared in patterns which
needs to be declared before the matching expressions that initialize
them.
TEST=existing expectations tests
Change-Id: I80ab1138f08f725f3e01905c1a57a1483f809328
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/291820
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>