Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Destructuring with explicit type of nullable record is a parsing error. #52439

Closed
water-mizuu opened this issue May 18, 2023 · 2 comments
Closed
Assignees
Labels
area-front-end Use area-front-end for front end / CFE / kernel format related issues. front-end-fasta type-bug Incorrect behavior (everything from a crash to more subtle misbehavior)

Comments

@water-mizuu
Copy link

As said in the title, the simplified code below is not accepted.

typedef Index = (int y, int x);

void main() {
  var (int y, int x) = (1, 3);
  var (bool reset, (int, int, int)? color) = switch ((y, x)) {
    Index ind when ind != ind => (true, (0, 128, 128)),
    _ => (false, null),
  };
}

Removing the question mark parses correctly, or by creating a type alias works as well.

typedef Index = (int y, int x);
typedef Color = (int r, int g, int b);

void main() {
  var (int y, int x) = (1, 3);
  var (bool reset, Color? color) = switch ((y, x)) {
    Index ind when ind != ind => (true, (0, 128, 128)),
    _ => (false, null),
  };
}
@lrhn lrhn added type-bug Incorrect behavior (everything from a crash to more subtle misbehavior) front-end-fasta area-front-end Use area-front-end for front end / CFE / kernel format related issues. labels May 18, 2023
@johnniwinther
Copy link
Member

cc @stereotype441 @jensjoha

@jensjoha jensjoha self-assigned this May 22, 2023
@stereotype441
Copy link
Member

Fixed in 284296f.

copybara-service bot pushed a commit that referenced this issue May 30, 2023
…ation.

Two of these tests (`recordPattern_nullable_beforeAs` and
`recordPattern_nullable_beforeWhen`) verify that the fix for #52439
(Destructuring with explicit type of nullable record is a parsing
error), which causes `(...)? identifier` to be recognized as a
variable pattern, doesn't get confused by the pseudo-identifiers `as`
and `when`, and so it continues to correctly parse `(...)? as ...` as a
cast pattern and `(...)? when ...` as a guarded pattern.

The other two tests (`recordPattern_nonNullable_beforeAs` and
`recordPattern_nonNullable_beforeWhen`) verify that `(...) as ...` and
`(...) when ...` are parsed correctly. These forms were never broken,
but they were not well tested either.

Bug: #52439
Change-Id: I866e1c7a6a8e47e0cd91a1a77654405f395b50da
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/305844
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-front-end Use area-front-end for front end / CFE / kernel format related issues. front-end-fasta type-bug Incorrect behavior (everything from a crash to more subtle misbehavior)
Projects
None yet
Development

No branches or pull requests

5 participants