This moves pattern variable assignments of fully matched expressions into the case body. This will help backends (dart2js in particular) to reason about the code flow.
Closes#54115
Change-Id: I598a384a829f16e91ab2d6a309499cf20b9cc121
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/339122
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
This changes the pattern matching lowering to avoid using late final variables (or lowerings thereof) and instead inline the initializer where used. This avoids generating closures that are hard for backends to reason about and optimize.
Closes#52805Closes#53804
Change-Id: Ia887446dd4d4475d05cf852c812bfe4b851de261
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/338860
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
General approach: Find all scopes for an offset,
then pick "the right one".
This still leaves a few offsets where we can't pick 1 scope in the
(non-outline) dills in the out directory though.
More thorough testing will follow.
TEST=ci
Change-Id: I66448498e07aa03f720733bcaf167bbfa30bca2f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/338840
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
FunctionTearOff node represents a tear-off of the 'call' method of
a Function, so it is basically a no-op:
FunctionTearOff(receiver) == receiver
So we can remove this node early, during lowering transformation on
kernel AST and clean up handling of FunctionTearOff nodes from the VM
and dart2wasm compilation pipelines.
TEST=ci
Change-Id: Ia1500a066a0261076162e018ff0ab502258f606f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/325924
Reviewed-by: Ömer Ağacan <omersa@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This simplifies handle the constructor/member and its corresponding
tearoff as a pair. Also it prepare for supporting tearoff of
extension type constructors and methods with the same name.
TEST=existing
Change-Id: Iea6cbc0250c8df6bd0f825068c1f3e865d938427
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/324202
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Previously the type inference was repeated in order to obtain the
static type of the iterable expression. That type is computed in the
shared analysis, and this CL passes the computed type to the clients
of the analysis routine in the result object.
In addition to being redundant, the repeated inference pass caused
crashes.
Closes https://github.com/dart-lang/sdk/issues/53092
Change-Id: I63d3d82be046884fa16d904a43e3bb6e01cf6f7e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/321141
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Chloe Stefantsova <cstefantsova@google.com>
This add support for patterns in textual outline by requiring callers
to pass an 'enablePatterns' flags. For incremental compilation this is
derive from the previously built library. For the textual outline suite
this is derived from the experimental flags.
Change-Id: Iebf420162c83808e2d0e2acb6e7fc147fec5c617
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/320520
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This renames InlineClass to ExtensionTypeDeclaration, and InlineType
to ExtensionType. Members of extension type declarations are called
extension type members instead of extension type declaration members
for "brevity".
TEST=existing
Change-Id: I91ed62533ddd345644492f04dc3310d007460288
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/316780
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
This is not the flag you're looking for.
The 'extension-types' flag was used for an early experiment that is
not directly related to the Extension Types feature currently being
developed. The current feature uses the 'inline-class' flag.
Change-Id: Icbb6c3828c41e743e726161b17da4c7784a2c677
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/316380
Reviewed-by: William Hesse <whesse@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Prior to this change, the first phase of flow analysis, in which flow
analysis "looks ahead" to see which variables are potentially assigned
in each code block, was failing to properly account for variables that
are assigned by pattern assignment expressions. This "look ahead"
information is used by flow analysis to determine the effects of
nonlinear control flow (e.g. to figure out which variables to demote
at the top of a loop, or to figure out which variables are potentially
assigned inside a closure). As a result, it was possible to construct
correct code that would be rejected by the analyzer and compiler, as
well as incorrect code that would (unsoundly) be accepted.
The fix is to call `AssignedVariables.write` from the analyzer's
`FlowAnalysisVisitor`, and from the CFE's `BodyBuilder`, to let flow
analysis know about variable assignments that occur inside pattern
assignment expressions.
Fixes#52745.
Change-Id: I0e6f426a5c5c36f214d5a206aaf5a2de0bfdaac1
Bug: https://github.com/dart-lang/sdk/issues/52745
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/310502
Auto-Submit: Paul Berry <paulberry@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
This changes the pattern lowering to use unchecked AsExpression
instead of promoted VariableGet when this occurs within a late
cache variable initializer. This is done to avoid promoted variables
that violate the (otherwise used) conservative reasoning about the
execution order of closures.
The unchecked AsExpressions are now shown in the ast-to-text.
Change-Id: I4fa6813f3b5cc73d9cdac17054de59e5d4b8ce7d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/307044
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Nate Biggs <natebiggs@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>
This allows void typed switch expressions by allowed void typed
expressions in all subexpressions inferred through the shared type
analysis.
This might lead to allowing void in intended places but the current
approach employed by the CFE doesn't really scale so we need to revisit
it anyway.
In response to https://github.com/dart-lang/sdk/issues/52191
Change-Id: Iee53670d3c316764cfc1309dc76cf37bb3b03629
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/299020
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Johnni Winther <johnniwinther@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>
In unsound null safety a throw expression is added as the last case
of switches without default to ensure that `null` doesn't fall through.
A break statement needs to be inserted in the last case if it doesn't
itself terminate.
Closes#51957
Change-Id: Ib63059aa2a00ebf1d7e49941af3b1c8acfc696f4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/293603
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Johnni Winther