Expansion info is reset for the mark

[dtolnay]

format_args!({ #[derive(repro)] struct ProcMacroHack; });

Correct behavior on all compilers 1.15.0 through 1.28.0-beta.10:

error: format argument must be a string literal.
 --> src/main.rs:5:18
  |
5 |     format_args!({ #[derive(repro)] struct ProcMacroHack; });
  |                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

But on nightly:
(UPDATE: The ICE is now suppressed, but the issue still needs investigation.)

thread 'main' panicked at 'expansion info is reset for the mark 2
old: ExpnInfo {
    call_site: Span {
        lo: BytePos(
            56
        ),
        hi: BytePos(
            113
        ),
        ctxt: #0
    },
    def_site: None,
    format: MacroBang(
        format_args
    ),
    allow_internal_unstable: true,
    allow_internal_unsafe: false,
    local_inner_macros: false,
    edition: Edition2015
}
new: ExpnInfo {
    call_site: Span {
        lo: BytePos(
            88
        ),
        hi: BytePos(
            109
        ),
        ctxt: #0
    },
    def_site: None,
    format: MacroAttribute(
        derive(repro)
    ),
    allow_internal_unstable: true,
    allow_internal_unsafe: false,
    local_inner_macros: false,
    edition: Edition2015
}', libsyntax_pos/hygiene.rs:114:17
note: Run with `RUST_BACKTRACE=1` for a backtrace.

error: internal compiler error: unexpected panic

---

Repro script

#!/bin/sh

cargo new repro
cargo new --lib repro_macro

cat >repro/src/main.rs <<'REPRO'
#[macro_use]
extern crate repro_macro;

fn main() {
    format_args!({ #[derive(repro)] struct ProcMacroHack; });
}
REPRO

cat >>repro/Cargo.toml <<'REPRO'
repro_macro = { path = "../repro_macro" }
REPRO

cat >repro_macro/src/lib.rs <<'REPRO'
extern crate proc_macro;
use proc_macro::TokenStream;

#[proc_macro_derive(repro)]
pub fn repro(_input: TokenStream) -> TokenStream {
    "".parse().unwrap()
}
REPRO

cat >>repro_macro/Cargo.toml <<'REPRO'
[lib]
proc-macro = true
REPRO

cargo build --manifest-path repro/Cargo.toml

---

Mentioning @petrochenkov because this bug was exposed by #51726.

[pnkfelix]

visiting for triage.

@petrochenkov do you have any status update to report here?

[petrochenkov]

No updates, low priority.
I'll look into this after edition-related macro modularization work is complete.

[petrochenkov]

In the worst case, the issue can be masked by turning the assert into debug assert.

[pnkfelix]

downgrading to P-medium to reflect lower-priority status.

[nikomatsakis]

@petrochenkov

In the worst case, the issue can be masked by turning the assert into debug assert.

So do we want to remove the assertion and file a follow-up issue to resurrect it? Seems like we should "close the issue" by doing that?

Some discussion here