internal compiler error: missing type for const item

[dwrensha]

I'm seeing an internal compiler error on the following input (found by fuzz-rustc):

macro_rules! suite {
    ( $( $fn:ident; )* ) => {
        $(
            const A = "A".$fn();
        )*
    }
}

suite! {
    len;
    is_empty;
}

fn main() {}

$ rustc src/main.rs
error: internal compiler error: missing type for `const` item
  --> src/main.rs:4:19
   |
4  |               const A = "A".$fn();
   |                     ^ help: provide a type for the item: `A: <type>`
...
9  | / suite! {
10 | |     len;
11 | |     is_empty;
12 | | }
   | |_- in this macro invocation
   |
   = note: src/librustc_errors/lib.rs:456: already existing stashed diagnostic with (span = Span { lo: BytePos(80), hi: BytePos(81), ctxt: #3 }, key = ItemNoType)
   = note: this error: internal compiler error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)

thread 'rustc' panicked at 'Box<Any>', src/librustc_errors/lib.rs:461:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports

note: rustc 1.43.0-nightly (7760cd0fb 2020-02-19) running on x86_64-unknown-linux-gnu

error: missing type for `const` item
  --> src/main.rs:4:19
   |
4  |               const A = "A".$fn();
   |                     ^ help: provide a type for the item: `A: <type>`
...
9  | / suite! {
10 | |     len;
11 | |     is_empty;
12 | | }
   | |_- in this macro invocation
   |
   = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)

error: aborting due to 2 previous errors

[dwrensha]

I ran cargo-bisect-rustc:

searched nightlies: from nightly-2019-07-30 to nightly-2020-02-15
regressed nightly: nightly-2019-09-26
searched commits: from 6ef275e to 37538aa
regressed commit: dcd473d

That's a rollup commit. Of the components of the rollup, #64698 looks to me to be most likely to be related. (cc @Centril)

[Centril]

Hmm, bummer. It looks like they are getting the same span and so the stashed error is overwritten. We might need to insert a Vec<_> there to handle the possibility of span reuse from different things.

[pnkfelix]

triage: P-high. Removing nomination. Added regression stable-to-stable tag.

[Centril]

Fixed in #69537.