-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Comments
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 |
Interesting, so |
I see what you mean (replacing |
This comment was marked as outdated.
This comment was marked as outdated.
I beg to differ: #[cfg(FALSE)]
fn f () {
match () {
() => { [0] }[..],
}
}
#[cfg(FALSE)]
fn f () {
match () {
() => unsafe { [0] }[..],
}
}
Edit: Apart from |
Ah whoops I was testing it differently by accident |
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. |
You can go ahead and ask if you'd like |
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? |
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. |
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:
rust-analyzer version: 0.3.1131-standalone (897a7ec 2022-07-17)
rustc version: rustc 1.64.0-nightly (f8588549c 2022-07-18)
The text was updated successfully, but these errors were encountered: