Previously, if a pattern variable declaration appeared outside of a
function or method, the parser would get very confused. Now it
recognizes the situation, issues a comprehensible error message, and
replaces the pattern with a synthetic identifier token so that the
analyzer AST is somewhat sensible.
Fixes#51322.
Bug: https://github.com/dart-lang/sdk/issues/51322
Change-Id: Ica5f060cb483a39c4e50942d639939b1fab40bea
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/293087
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The type name in an object pattern is a `typeIdentifier`; in the spec
grammar, `typeIdentifier` includes `OTHER_IDENTIFIER`, which is defined as:
OTHER_IDENTIFIER ::=
`async` | `hide` | `of` | `on` | `show` | `sync` | `await` | `yield`
This adds tests to verify that all these identifiers are accepted as
type names in an object pattern.
Bug: https://github.com/dart-lang/sdk/issues/50035
Change-Id: I6b9d752e1b34f7bc93dedc4304f695e7cb42df48
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/292542
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@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>
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>
This allows the parser to parse constant patterns at lower precedence
level in order to recognize more expressions in this context. To
support this, _parsePrecedenceExpressionLoop special cases a few cases
that should _not_ be parsed as expression in a constant pattern context.
Closes#50996
Change-Id: I43bb0ce52d366bd2dfcf47e12eec5883402f668a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/282100
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Variable patterns behave so differently inside a patternAssignment
that we may want to represent them using different AST nodes inside
the analyzer/CFE. This change adds a boolean flag allowing the
implementation to know what kind of variable pattern it's looking at
when parsing occurs.
Bug: https://github.com/dart-lang/sdk/issues/50035
Change-Id: I60adf2865bbe24f85b72a79b1360833bf823bd67
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/273829
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Expressions can also occur in patterns, either after an equality or
relational operator (e.g. `== e`), or after `const` (though what's
allowed after `const` is heavily restricted). We need to make sure
that the expression parser doesn't greedily treat `=>` as introducing
a function expression when parsing these constructs inside a switch
expression.
But it's ok to allow function expressions inside list patterns, map
patterns, parenthesized patterns, and in the argument part of object
patterns. (These will be rejected by a later stage of analysis
because expressions inside of patterns must be const, and a function
expression can't be const. But the parser should still accept them so
that we can give useful error messages).
Fixes#50591.
Bug: https://github.com/dart-lang/sdk/issues/50591
Change-Id: I828555782f5bc8cb8aae8a3948849b7a75bdec57
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/273286
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The parser now handles maps that contain rest patterns with
subpatterns (e.g. `{'foo': _, ...var rest}`). Even though this is
invalid Dart, it still makes sense for the parser to handle it so that
we can generate higher quality error messages.
The shared type analyzer now generates an error,
`restPatternWithSubPatternInMap`, if it encounters this error
condition.
Change-Id: I7f447bde28e646593aa432e3e5ad1f5e415bdd30
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/273283
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Previously, the implementation used `&` and `|` for logical-and and
logical-or patterns. That is being changed to `&&` and `||`.
As a first step, we add support for `&&` and `||`, without removing
support for `&` and `|`. In a follow-up CL I'll update existing
tests, and then after a day or two I'll remove support for `&` and
`|`. This should avoid conflicts with other patterns work that's in
progress.
Bug: https://github.com/dart-lang/language/issues/2501
Change-Id: I2d5dc158248160d84e9f0889f5de390b999cbc7e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/272861
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Paul Berry