Add -Z span-debug to allow for easier debugging of proc macros

[Aaron1011]

Currently, the Debug impl for proc_macro::Span just prints out
the byte range. This can make debugging proc macros (either as a crate
author or as a compiler developer) very frustrating, since neither the
actual filename nor the SyntaxContext is displayed.

This commit adds a perma-unstable flag -Z span-debug. When enabled,
the Debug impl for proc_macro::Span simply forwards directly to
rustc_span::Span. Once #72618 is merged, this will start displaying
actual line numbers.

While Debug impls are not subject to Rust's normal stability
guarnatees, we probably shouldn't expose any additional information on
stable until #![feature(proc_macro_span)] is stabilized. Otherwise,
we would be providing a 'backdoor' way to access information that's
supposed be behind unstable APIs.

[rust-highfive]

r? @varkor

(rust_highfive has picked a reviewer for you, use r? to override)

[Mark-Simulacrum]

I would personally lean towards avoiding the -Z flag and just implementing Debug for the proc_macro::Span type. If people are parsing the output of Debug impls then they're basically asking for trouble, I think it's fine if we end up breaking that in the future. (We can also add an explicit note to the documentation that such parsing is not permitted, and potentially even to the debug output itself).

[Aaron1011]

@Mark-Simulacrum: In the discussion about proc_macro_span, @matklad had raised some concerns about the interaction with incremental compilation: #54725 (comment)

If people are parsing the output of Debug impls then they're basically asking for trouble

I agree. However, I'd like to avoid even the possibility of breakage until some kind of consensus has been reached about what we do or do not want to expose to proc macros. Even if the majority of crates don't abuse the Debug impl, it only takes a few to complicate things.

[Aaron1011]

Additionally, I don't think we'd ever want to forward to an internal Debug impl for a stable method. If we do end up changing the output on stable, we should probably decide on a desired format, and print exactly the fields we want.

[petrochenkov]

I'd personally keep this as a private patch that I apply only when actually debugging tokens streams (it's a one line change), but -Z flag is unstable and not a high cost, so it should be ok I guess.

[petrochenkov]

To elaborate, you never know what you'll need during next debugging.
Today it's more detailed span info, tomorrow it's some additional information about types or logging in some random place, I already said this about debug! in #68941 (comment), same argument applies here.
So I remove all my debugging stuff before submitting PRs, for example.

[Aaron1011]

To elaborate, you never know what you'll need during next debugging.
Today it's more detailed span info

My goal is to make the Span debugging experience more consistent - right now, you get a useful debug printout from compiler code, but a pretty useless one from a proc macro.

A -Z flag also has the advantage that it can easily be enabled when bisecting nightly builds.

[Aaron1011]

@petrochenkov: Updated

[petrochenkov]

Thanks!
r=me

(This will fail tidy and conflict with #72618 though.)

[Aaron1011]

@bors r=petrochenkov

[bors]

📌 Commit b583f33a7db66ffce3394e4dce7d663ddce2820c has been approved by petrochenkov

[petrochenkov]

@Aaron1011
Could you address #72799 (comment)?

[Aaron1011]

@bors r-

[Aaron1011]

@petrochenkov: Fixed

[petrochenkov]

@bors r+

[bors]

📌 Commit b541d3d has been approved by petrochenkov