Open SimonSapin opened 8 years ago
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.
The trouble is you get the same error if you screw up writing the macro, e.g. misspell @inner
or order something backwards in one of the arms. It isn't the caller's fault for sure.
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.
Current output:
error: recursion limit reached while expanding the macro `match_ignore_ascii_case`
--> src/main.rs:3:27
|
3 | ( $($rest:tt)* ) => { match_ignore_ascii_case!(@inner $($rest)*) };
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...
12 | match_ignore_ascii_case!(2 => 3);
| --------------------------------- in this macro invocation
|
= help: consider adding a `#![recursion_limit="128"]` attribute to your crate
Triage: no change.
Triage: no change.
Consider this reduced test case:
The
@inner
indirection exists because the non-reduced macro is recursive: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.
The error message looks even worse when the macro is used (with incorrect syntax) from another crate