-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Suggest adding missing braces in const
block pattern
#78173
Conversation
3e567f0
to
0bf61fd
Compare
@@ -1060,8 +1060,8 @@ impl<'a> Parser<'a> { | |||
}) | |||
} else if self.eat_keyword(kw::Unsafe) { | |||
self.parse_block_expr(None, lo, BlockCheckMode::Unsafe(ast::UserProvided), attrs) | |||
} else if self.check_inline_const() { | |||
self.parse_const_expr(lo.to(self.token.span)) | |||
} else if self.eat_keyword(kw::Const) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think @petrochenkov and others wanted to avoid eating the keyword before checking if it's really an inline const. My first reaction was like ... but we're eating Unsafe
right above. I'm not sure if there's another way to solve this problem and we could still rely on checking or if we just need to eat the keyword.
Anyway, would leave this to @petrochenkov
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The difference is that unsafe
just modifies the block expression, whereas const
needs to create the ExprKind::Const
- but maybe it doesn't have to be too complicated shrug.
Another thought, I've 2 PRs open for inline consts that changes in some way the code you're also touching. It may be good to land those first and base your work on those. |
Yeah, I expected to have merge conflicts :) Weirdly, GitHub is reporting merge conflicts but bors is not. I think this issue has happened before; I’ll let T-infra take a look before I fix the conflicts so they can perhaps figure out the cause. |
b9e3545
to
31e18af
Compare
Rebased. |
| | ||
LL | let const = "foo"; | ||
| ^^^^^ expected identifier, found keyword |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This has regressed a bit now.
cc @oli-obk
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The thing is that this:
let const { "foo" } = "foo";
is a totally valid statement (although it ICEs; see #78174). Perhaps we could give the old warning if it's just const
and then =
immediately after?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see, but, what do you expect that code to do?.
I'd expect an error anyway something like error[E0005]: refutable pattern in local binding: ``&_`` not covered
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's valid syntactically, not semantically. (And either way it shouldn't ICE.)
And yes, the error you suggested is correct; it's the one that occurs for let "foo" = "foo";
: error[E0005]: refutable pattern in local binding: `&_` not covered
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
exactly, 👍
Now both of my follow up PRs are in and you would need to rebase again :). I think this is fine modulo the Anyway, this is fine by me but would leave this up to r? @petrochenkov |
a75494e
to
19ec18b
Compare
@camelid So I suggest to parse In patterns we have the unary |
I'm hoping to get to this at some point soon, I just need to understand this part of the codebase better. |
This can be split into two parts - one for expressions (which should be pretty much a copypaste of what |
Previously it would only suggest wrapping the code in braces in regular expressions; now it does it in patterns too.
Needed for range pattern parsing.
Starting with a rebase. |
502fcec
to
d9dfa89
Compare
@petrochenkov One issue with this is that prefix operators have high precedence, so the suggestion for wrapping the code in a block doesn't capture what it should:
I'm not sure if there's a good way to resolve this because of the precedence of prefix operators. I haven't made many changes to the parser before, so I would appreciate some extra guidance! Thanks :) |
|
Closing due to inactivity. |
Previously it would only suggest wrapping the code in braces in regular expressions; now it does it in patterns too. This is a squashed rebase of rust-lang#78173
Previously it would only suggest wrapping the code in braces in regular expressions; now it does it in patterns too. This is a squashed rebase of rust-lang#78173
Previously it would only suggest wrapping the code in braces in regular expressions; now it does it in patterns too. This is a squashed rebase of rust-lang#78173
Fixes #78168.
Previously it would only suggest wrapping the code in braces in regular
expressions; now it does it in patterns too.
r? @spastorino