-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Restrict parse_maybe_literal_minus
#129289
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
base: master
Are you sure you want to change the base?
Restrict parse_maybe_literal_minus
#129289
Conversation
It covers some patterns that are relevant for upcoming changes to `parse_literal_maybe_minus`.
The end goal is to only allow `ExprKind::Lit` and `ExprKind::Unary`/`Unop::Neg` interpolated expressions. We can't do that yet, because we still need to allow `ExprKind::Path` and `ExprKind::MacCall`. Some tests have their output changed, because some invalid code is now rejected during parsing instead of during HIR lowering. Each error location moves from a macro call site to a macro body, which I think is an improvement.
The original version of #126571 tried to ban all There are follow-ups to be done to remove |
@bors try |
…minus-1, r=<try> Restrict `parse_maybe_literal_minus` `parse_literal_maybe_minus` currently accepts to many kinds of `NtExpr`. This PR starts the process of restricting it. r? `@petrochenkov`
☀️ Try build successful - checks-actions |
🚨 Error: missing desired crates: {"htmx-rs"} 🆘 If you have any trouble with Crater please ping |
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
🚧 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
🎉 Experiment
|
There is one real regression. If I allow |
Here's an interesting test case: macro_rules! p2 {
($m:pat) => {}
}
macro_rules! p1 {
($m:expr) => { p2!($m) };
}
fn main() {
// Reasonable expression patterns, that are currently accepted, and
// show up in a crater run.
p1!(());
p1!((3,4));
// Reasonable expression patterns, that are currently accepted, but
// dont't show up in a crater run.
p1!([3,4]);
p1!(&x);
p1!(..);
p1!(Foo(x, y));
p1!(Foo { x, y });
// Unreasonable expression patterns, that are currently accepted, but
// don't show up in a crater run.
p1!(f());
p1!(x.f());
p1!(1 + 1);
p1!(x as u32);
p1!(if a { b } else { c });
p1!(loop {});
p1!(x = 3);
p1!((3)); // maybe a reasonable pattern?
} Currently this compiles without any problem because |
After migrating to the token model - everything that fits into both the expression and the pattern syntax as tokens. Before the migration - no strong opinion, just not more than after the migration, and no large breakage. |
Still waiting on the author to answer. |
Unsure. The current behaviour isn't great, but fixing it turns out to be more complex than I expected, so this PR has fallen a long way down my todo list :( |
parse_literal_maybe_minus
currently accepts to many kinds ofNtExpr
. This PR starts the process of restricting it.r? @petrochenkov