Repository navigation
Bad macro usage error message does not include correct error location #31022
Description
Consider this reduced test case:
macro_rules! match_ignore_ascii_case {
(@inner $value:expr) => { () };
( $($rest:tt)* ) => { match_ignore_ascii_case!(@inner $($rest)*) };
}
fn main() {
// This is fine
match_ignore_ascii_case!(1);
// This causes an error as it doesn’t match the expected syntax
// but the error message does not the location of the actual error.
match_ignore_ascii_case!(2 => 3);
}The @inner indirection exists because the non-reduced macro is recursive:
- https://play.rust-lang.org/?gist=f8b1652f43cc720f89a3&version=nightly
- https://users.rust-lang.org/t/writing-a-macro-rules-macro-used-like-a-match-expression/4328
This fails to compile (as it should) but the error message does not include the real location of the error, which is line 12. It can be hard to track down in a large crate with many users of the macro.
a.rs:3:52: 3:53 error: unexpected token: `@`
a.rs:3 ( $($rest:tt)* ) => { match_ignore_ascii_case!(@inner $($rest)*) };The error message looks even worse when the macro is used (with incorrect syntax) from another crate
<cssparser macros>:12:1: 12:2 error: unexpected token: `@`
<cssparser macros>:12 @ inner $ value , ( $ ( $ rest ) * ) -> (
Activity
Make match_ignore_ascii_case! future-proof.
Auto merge of #91 - servo:macro, r=SimonSapin
durka commentedon Jan 19, 2016
When the expanded code contains a non-macro-related error (say, a type mismatch), it at least shows a macro expansion backtrace. It's very hard to read, but gives spans at least. I guess that would be a start.
durka commentedon Jan 19, 2016
The trouble is you get the same error if you screw up writing the macro, e.g. misspell
@inneror order something backwards in one of the arms. It isn't the caller's fault for sure.SimonSapin commentedon Jan 20, 2016
Yes, I don’t have an example at hand to copy/past but I see the kind of error message you mean. It may be the caller’s fault even if it isn’t necessarily. A macro expansion backtrace would be useful here.
estebank commentedon Sep 21, 2017
Current output:
estebank commentedon May 22, 2019
Triage: no change.
estebank commentedon Jun 8, 2022
Triage: no change.
estebank commentedon Dec 28, 2022
Triage: no change.
estebank commentedon Aug 8, 2026
@SimonSapin do you have any recollection of this ticket? I am tempted to close (we now do point at line 12 after all) and I'm not sure how we can improve it. Do you feel we should keep this ticket around?
SimonSapin commentedon Aug 8, 2026
I don’t remember this but based given that I wrote:
… and that the new message does point to line 12, I think we can close this as fixed. Looks like we could even have closed in 2017, sorry I didn’t realize!