Restrict parse_maybe_literal_minus#129289
Restrict parse_maybe_literal_minus#129289nnethercote wants to merge 2 commits intorust-lang:mainfrom
parse_maybe_literal_minus#129289Conversation
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_minuscurrently accepts to many kinds ofNtExpr. This PR starts the process of restricting it.r? @petrochenkov