My code fails to build with „unexpected end of macro invocation“ since nightly 2017-07-02

[vorner]

Hello

I have this code: https://gitlab.labs.nic.cz/turris/pakon-aggregator (unfortunately, I don't have a minimal code example yet). It fails with rustc 1.20.0-nightly (067971139 2017-07-02) (for some reason this is the version I get if I run rustup default nightly-2017-07-03, it seems to be one day off) and newer, but passes with older versions of nighly as well as stable and beta.

The error I get is:

error: unexpected end of macro invocation
   --> src/keeper/column.rs:269:1
    |
269 | / column! {
270 | |     /// Identifier of an address inside an endpoint.
271 | |     ///
272 | |     /// This is usually used to specify aggregation by a value in queries.
...   |
357 | |     name Port u16;
358 | | }
    | |_^ in this macro invocation
    |
    = note: this error originates in a macro outside of the current crate

This is actually my own macro, so the „originates in a macro outside of the current crate“ part is wrong. Also, renaming the macro makes it compile again. This leads me to think something (the compiler) brought in a colliding macro with the same name.

Is my theory about the colliding macro true? Can this killing of my poor innocent macro be prevented somehow? Should local macros have precedence? Or, at least, should I get a better error message, like complaining when I define the macro, not when I use it? This makes me think that if I had the bad luck of having a same-name macro with the same invocation syntax, it would silently expand the wrong one.

Exact version

$ rustc --version --verbose
rustc 1.20.0-nightly (067971139 2017-07-02)
binary: rustc
commit-hash: 0679711398bef656699e1ff6b004ecccbdb67284
commit-date: 2017-07-02
host: x86_64-unknown-linux-gnu
release: 1.20.0-nightly
LLVM version: 4.0

[kennytm]

Not sure if it is relevant, but there is already a column! macro in the standard library.

[TimNN]

Minimized, side effect of #42938:

macro_rules! column { (foo) => { panic!() } }

fn main() {
    column!(foo);
}

[TimNN]

Or alternatively with a singularly unhelpful error message (column! isn't even used here, just defined):

macro_rules! column { (foo) => {} }

fn main() { panic!(); }

error: unexpected end of macro invocation
 --> <anon>:4:5
  |
4 |     panic!();
  |     ^^^^^^^^^
  |
  = note: this error originates in a macro outside of the current crate

[PlasmaPower]

Same thing happens with a file or line macro. #42938 just added column to the list. Should macros with those names be illegal, or should we work around them?

[kennytm]

panic!() should use core::{file,line,column}!(). IIRC rust already has the qualified macro feature.

[TimNN]

So I guess there are three "issues" here:

1. If a macro expands to another macro, that macro is resolved where the expansion happens, not the definition (although that is expected as far as I know)
2. We have macros in std which depend on other macros from std being available as defined in std. This is bad in my opinion and should maybe be fixed (one idea would be to to make macros like column! available as _rust_std_column! as well, for use in std. This would at least reduce the likelihood of them being redefined Live Edit: Even better what @kennytm said Real Edit: that doesn't work for compiler-provided macros like column!).
3. Output column number info when panicking #42938 added a call to column! inside of panic! which causes the regression here.

---

Edit: Tagging as T-libs since the definition of the panic! macro is their responsibility although I guess compiler/lang may be applicable as well.

[TimNN]

@kennytm: Sadly, that doesn't work: file!, line! and column! are compiler-builtin macros that don't exist in any crate.

[PlasmaPower]

An empty implementation, however, does exist at the std/core root (presumably for documentation reasons). I don't know much about the compiler internals, but would it be possible to "fill in" that implementation, instead of creating a "new" builtin macro?

[vorner]

I see, so there was the column! macro in the library to start with and I should rename it.

Still, I think the error message could be a bit more helpful.

[PlasmaPower]

@vorner Your macro definition shouldn't interfere with the standard library, but yes, that's what's currently happening.

I realized that my proposed "filling in" solution also wouldn't work with #![no_core]. I'm not sure how to approach this.

[kennytm]

Since #![no_core] is unstable I think telling the developers to use __rust_std_column__!() instead of column!() is permitted.

There should be a lint which warns about shadowing any of the built-in macros.

(Alternatively, would it be possible to rewrite file!, line!, column! as procedural macros (instead of libsyntax built-in plugins) that respects #35896 (macro modularization)? #![no_core] developers would still need to #[macro_use] extern crate core_macros; to use them.)