-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
internal compiler error: unprintable span #31011
Comments
Code showing the issue is available at https://notabug.org/rillian/mp4parse-rust/src/issue-31011 I see this with both 1.5 stable and 17 nightly. cc @gankro |
Here's a simpler example: https://play.rust-lang.org/?gist=fd7e6bbc22a85d299bdd |
And an even simpler one: https://play.rust-lang.org/?gist=8d172764fd95ff346bed |
The ICE does not occur without the macro. This prints the compile error cleanly: https://play.rust-lang.org/?gist=7459e2ba9918ba9e56c1 |
This is a work in progress PR that potentially should fix #29084, #28308, #25385, #28288, #31011. I think this may also adresse parts of #2887. The problem in this issues seems to be that when transcribing macro arguments, we just clone the argument Nonterminal, which still has to original spans. This leads to the unprintable spans. One solution would be to update the spans of the inserted argument to match the argument in the macro definition. So for [this testcase](https://github.com/rust-lang/rust/compare/master...fhahn:macro-ice?expand=1#diff-f7def7420c51621640707b6337726876R2) the error message would be displayed in the macro definition: src/test/compile-fail/issue-31011.rs:4:12: 4:22 error: attempted access of field `trace` on type `&T`, but no field with that name was found src/test/compile-fail/issue-31011.rs:4 if $ctx.trace { Currently I've added a very simple `update_span` function, which updates the span of the outer-most expression of a `NtExpr`, but this `update_span` function should be updated to handle all Nonterminals. But I'm pretty new to the macro system and would like to check if this approach makes sense, before doing that.
Trying to access a struct member from a macro inside a parameterized closure, I get:
The code may well be wrong, but I thought the internal compiler error was worth reporting.
The text was updated successfully, but these errors were encountered: