-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Suggest enclosing const expression in block #64700
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Conversation
r? @eddyb (rust_highfive has picked a reviewer for you, use r? to override) |
This comment has been minimized.
This comment has been minimized.
src/libsyntax/parse/parser/expr.rs
Outdated
@@ -186,6 +186,12 @@ impl<'a> Parser<'a> { | |||
self.last_type_ascription = None; | |||
return Ok(lhs); | |||
} | |||
(true, Some(AssocOp::Greater)) if self.restrictions.contains( |
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 can't say I'm following the changes in this particular file and how it is hanging together & will need some help with that. As this is subtle, it would be good if @petrochenkov could also give this a look.
06847d7
to
39ae744
Compare
r? @petrochenkov for some more reviewing. |
|
We can always close this PR and use it as a reference once I do want to make the case that nightly features are "leaky", particularly in the parser because they cause subpar diagnostics with incomplete code, which is why I don't restrict myself to only stable features. Type ascription is a good example of how bad the diagnostics can be when not tackled, and how hard and far reaching the implications of the chosen syntax are. |
I think I have a more constructive suggestion today. For that to work, we need the expression parsing mode treating closing angle brackets specially anyway (like (*) Because (I need to go right now, will find the relevant links later.) |
Here it is - rust-lang/rfcs#1931 (comment), I was searching on the wrong RFC thread. So, the logic for parsing a generic argument is if can_begin_expr(token) && !can_begin_type(token) {
if !is_whitelisted(token) {
span_err("conservative error");
}
parse_expr(Restrictions::CLOSING_ANGLE_BRACKET)
} else {
parse_type()
} where |
39ae744
to
28d113e
Compare
This comment has been minimized.
This comment has been minimized.
28d113e
to
e5c7e5b
Compare
This comment has been minimized.
This comment has been minimized.
When encountering `foo::<1 + 1>()`, suggest `foo::<{ 1 + 1 }>()`. Fix rust-lang#61175.
e5c7e5b
to
370f4f5
Compare
Hello from triage. Thanks. |
@estebank |
Pinging again from triage. |
Ping from Triage: Hi @estebank, closing due to inactivity, please reopen when you have updates. Thanks for the PR. |
@rustbot modify labels to -S-inactive +S-inactive-closed |
@petrochenkov I started looking at this again and I am a bit confused. Should |
When encountering
foo::<X + 1>()
, suggestfoo::<{ X + 1 }>()
. When encounteringfoo::<1 + 1>()
orfoo::<1 + X>()
, parse correctly.Fix #61175.