-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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 enclosing const expression in block #64700
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.