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

Parsing issues around inline consts in match arms #12824

Closed
fmease opened this issue Jul 20, 2022 · 10 comments
Closed

Parsing issues around inline consts in match arms #12824

fmease opened this issue Jul 20, 2022 · 10 comments
Labels
A-parser parser issues S-unactionable Issue requires feedback, design decisions or is blocked on other work

Comments

@fmease
Copy link
Member

fmease commented Jul 20, 2022

Syntax support for #![feature(inline_const)] was added in #7010 (rust-analyzer/ungrammar#17).
However, r-a fails to parse the following code whereas rustc accepts it:

fn f() {
    match () {
        () => const { &["--release"] }[..],
        //    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Syntax Error: expected FAT_ARROW
    }
}

rust-analyzer version: 0.3.1131-standalone (897a7ec 2022-07-17)

rustc version: rustc 1.64.0-nightly (f8588549c 2022-07-18)

@fmease fmease changed the title Parsing issues around inline consts Parsing issues around inline consts in match arms Jul 20, 2022
@lnicola lnicola added S-actionable Someone could pick this issue up and work on it right now A-parser parser issues labels Jul 20, 2022
@Veykril Veykril self-assigned this Jul 20, 2022
@Veykril
Copy link
Member

Veykril commented Jul 20, 2022

Oh this is a funny one, we parse the block expression, then due to a bug here we consider the expression finished and since its a block there is no need for a comma, so we parse the slice expression as the pattern of the next arm

@Veykril
Copy link
Member

Veykril commented Jul 20, 2022

Interesting, so const blocks behave differently from normal blocks and unsafe blocks ...

@fmease
Copy link
Member Author

fmease commented Jul 20, 2022

Interesting, so const blocks behave differently from normal blocks and unsafe blocks ...

I see what you mean (replacing const with an empty string or with unsafe leads to an error with rustc, too).
Might be worth asking T-lang or whoever if this is intentional. Not sure.

@Veykril

This comment was marked as outdated.

@fmease
Copy link
Member Author

fmease commented Jul 20, 2022

Though these errors aren't parsing errors in rustc

I beg to differ:

#[cfg(FALSE)]
fn f () {
    match () {
        () => { [0] }[..],
    }
}
error: unexpected `,` in pattern
 --> src/lib.rs:4:27
  |
4 |         () =>  { [0] }[..],
  |                           ^
  |
help: try adding parentheses to match on a tuple...
  |
4 |         () =>  { [0] }([..],)
  |                       +     +
help: ...or a vertical bar to match on multiple alternatives
  |
4 |         () =>  { [0] }[..] |
  | 

#[cfg(FALSE)]
fn f () {
    match () {
        () => unsafe { [0] }[..],
    }
}
error: unexpected `,` in pattern
 --> src/lib.rs:4:33
  |
4 |         () => unsafe { [0] }[..],
  |                                 ^
  |
help: try adding parentheses to match on a tuple...
  |
4 |         () => unsafe { [0] }([..],)
  |                             +     +
help: ...or a vertical bar to match on multiple alternatives
  |
4 |         () => unsafe { [0] }[..] |
  |                             ~~~~~~

Edit: Apart from #[cfg(FALSE)], you can also pass -Zparse-only to rustc to double-check.

@Veykril
Copy link
Member

Veykril commented Jul 20, 2022

Ah whoops I was testing it differently by accident

@fmease
Copy link
Member Author

fmease commented Jul 20, 2022

Okay, so should I ask T-lang on Zulip or would you like to do the favor? Either one is fine for me.

Edit: Zulip stream.

@Veykril
Copy link
Member

Veykril commented Jul 20, 2022

You can go ahead and ask if you'd like

@fmease
Copy link
Member Author

fmease commented Jul 23, 2022

The discussion didn't lead to anything we could immediately act on. scottmcm added this issue to the list of unresolved questions on the tracking issue for inline consts (rust-lang/rust#76001). Seems like this r-a issue turns out to be S-unactionable?

@Veykril Veykril added S-unactionable Issue requires feedback, design decisions or is blocked on other work and removed S-actionable Someone could pick this issue up and work on it right now labels Jul 23, 2022
@Veykril Veykril removed their assignment Jul 24, 2022
@fmease
Copy link
Member Author

fmease commented Dec 4, 2022

Since rust-lang/rust#105142, rustc now correctly parses inline consts as ExpressionWithBlock instead of ExpressionWithoutBlock making the behavior of rustc & rust-analyzer equal & fixing this issue.

@fmease fmease closed this as completed Dec 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-parser parser issues S-unactionable Issue requires feedback, design decisions or is blocked on other work
Projects
None yet
Development

No branches or pull requests

3 participants