regression on span for panics due to track-caller in cross-crate macros

[nikomatsakis]

This example has regressed (including on stable by now): (playground)

fn main() {
    std::collections::VecDeque::<String>::with_capacity(!0);
}

The location reported is now <::core::macros::panic macros>:3:10 (or on nightly, src/libcore/macros/mod.rs:34:9).
(the choice of VecDeque::with_capacity is arbitrary, it just happens to have an assert! inside, and it will be codegen'd in the user crate because it's generic)

In general, we don't track enough information to recover the invocation site, when we have to codegen the MIR cross-crate.

A cheap hack we could do is replace the macro span with the invocation one, when serializing Spans inside MIR (or Spans in general?).

Originally posted by @eddyb in #47809 (comment)

[Centril]

cc @anp :)

[eddyb]

One way to handle replacing macro spans with invocation ones when serializing spans in MIR would be adding another Span to Terminator (or even just TerminatorKind::Call), that will only be used for the panic::Location passed to #[track_caller] callees.

Probably the easiest way to handle the custom encoding strategy is a SpanEncodedAsCallSite newtype that has a specializable Encodable impl, so that the cross-crate encoder can hook it.

[eddyb]

cc @Aaron1011 as they have been working on a proper implementation of hygiene serialization (which would make the workaround obsolete)

[anp]

Aha, I knew I was forgetting to file something that was ongoing. Is there an issue tracking the span hygeine work that’s ongoing?

[eddyb]

Is there an issue tracking the span hygeine work that’s ongoing?

Oh, there is: #68686.

[eddyb]

(Let me know if it's inappropriate to use regression-from-X-to-Y labels for runtime behavior)

[Mark-Simulacrum]

@rustbot prioritize

[spastorino]

Assigning P-medium as discussed as part of the Prioritization Working Group process and removing I-prioritize.