Is it possible to pass a span to compile_error!

[chancancode]

I noticed that this question from @Stebalien was left unaddressed in the compile_error! RFC:

Is the span information not attached to the tokens passed to a macro? I'd like to be able point out which token in the macro input caused the macro expansion to fail (and why).

Before compile_error! was a thing, I generally report errors to the user (where possible) by passing the offending token to a "sink" macro that has no possible matches, which would cause the compiler to report no rule expected the token <token> with the right span. It is nice that now I can specify a useful message, however we lost the ability to point the error back to the right span. It is unfortunate to have to make this trade-off (either providing the right span without telling you why, or telling you why without reporting where), and in some scenario neither of the two options on their own would be sufficient to understand the error (it could be a very generic error that could happen in a lot of places – think "missing a semicolon" or "unbalanced braces" kind of errors).

cc @sgrif

[chancancode]

cc @wesleywiser

[sgrif]

I explicitly left spans out of the original RFC, as there is no mechanism in place for dealing with spans anywhere in the macro system today, and I think such a change wouldn't be feasible without macros 2.0.

[chancancode]

As @Stebalien has pointed out, the span information is attached to the original tokens. The strategy I used previously (forcing a mismatch) does (and still) usually report the right span. Therefore the reality is that today you have the option to report the right span or a message, but not both.

[chancancode]

I think are a few possibilities.

Perhaps we can add a new macro, perhaps mismatch!(token, message) that produces a compile error with the token's span similar to the one you would get (no rules expected token...).

Another possibility is to make concat! somehow carry-forward the span from its input, so that you can produce the same message manually by concat!-ing the oftending token into the message that you pass to compile_error!

[sgrif]

Those both seem super implicit and magical to me. Either way I think something like that would require an RFC. I wonder if you could get a good 80/20 solution by using line!, column! and file!?

[chancancode]

line!, column! and file! won't work since they would point to the original/outermost macro invocation. If we can optionally pass the token to these macros the it would accomplish what we need.

[chancancode]

There is a sort-of work around though. Since the compiler doesn't stop at the first error, you can first force a mismatch, then give more details in a compile_error!: http://play.rust-lang.org/?gist=c321a3c88544586c9323da8cc967aa99&version=stable&mode=debug

The line information for the compile_error! is not very useful and potentially confusing, so ideally, we won't want to show that. However, this is probably good enough since the compiler would just point to the outer-most in-crate macro invocation (still not useful, but it is less likely to cause confusion).

[limira]

compile_error! is just give a half-usefulness in most cases. We need both why and where! Such as:

321 |          something_cause_error {
               ^^^^^^^^^^^^^^^^^^^^^ a useful message provided via compile_error here!

I like the work around by @chancancode above, but do in reverse:

macro_rules! give_me_foo_or_bar {
    (foo) => {};
    (bar) => {};
    ($x:ident) => {
        compile_error!("This macro only accepts `foo` or `bar`. Find location of error in next error");
        force_mismatch_on_error_token! ($x);
    }
}

[wesleywiser]

This may be of interest https://internals.rust-lang.org/t/custom-error-diagnostics-with-procedural-macros-on-almost-stable-rust/8113

[Mark-Simulacrum]

It does seem like ultimately what we want here is the diagnostics feature of macros stabilized, before that happens I don't expect this'll have too much movement, so I'm going to go ahead and close as it's edging on either "needs RFC" and/or "won't fix".