Open mpfaff opened 2 years ago
Thanks for the report!
This is definitely something we'll want to take a look at. I also want to point out that the deadlock case is a duplicate of #4442
I also want to point out that the deadlock case is a duplicate of #4442
Thanks for letting me know. I posted my example over there.
I appreciate the report @mpfaff and for your investigation @ytmimi, but want to be fully transparent that this will be a low priority.
There's very few macro calls which we provide special case handling for, and only do so in those cases because of a known, minimal set of arg tokens to expect, such as cfg_if
. While it would of course be better to handle this more gracefully, handling intentionally incorrect/invalid call args gracefully isn't a high priority compared to the myriad of other items on the backlog.
Another cfg_if
related issue popped up (#5428) so I started digging back into this. Although, diagnostic information is emitted, the invalid cfg_if
syntax here doesn't actually prevent the file from being formatted as demonstrated by the following example:
Input:
cfg_if! {
if
}
fn main(
) {
println!("hello world");
}
Output
cfg_if! {
if
}
fn main() {
println!("hello world");
}
If you invoke any macro named
cfg_if
with starting withif
and not following the rules of the macro of the same name provided by the cfg-if crate, rustfmt will panic.Here is a minimal example to reproduce the issue:
Output when running
RUST_BACKTRACE=1 rustfmt +stable lib.rs
:And when running
RUST_BACKTRACE=1 rustfmt +nightly lib.rs
:Line 7 of each backtrace hints that special support for the
cfg_if
macro is the culprit.Update 1:
This can also be triggered by
else if
, but reproducing it is a bit trickier, because it needs to avoid panicking on the firstif
:Update 2:
I can file a separate issue for this if that would be best, but for now I'll just tack it on here:
The special
cfg_if
handling can also deadlock as seen here: