Verify that the AST does not have DUMMY_SP

[arielb1]

Currently, syntax extensions can generate code with DUMMY_SP in its AST. All compiler diagnostics from that code, and all stack backtraces generated by that code, are basically worthless.

That should not be possible. The lowered HIR should not have any DUMMY_SP.

cc @rust-lang/compiler

[arielb1]

I think that if a syntax extension generates code with DUMMY_SP, we should use the span of its caller instead.

[cgswords]

While this is a good idea, it seems a better idea is to have the expander walk the plugin's output and respan anything with a DUMMY_SP to have the span of the macro invocation site. Doing this as part of expansion has a few advantages:

1. We don't have to produce errors here or worry about those checks during HIR lowering
2. This takes a lot of responsibility off of the plugin writer (most importantly, they won't have to pass span information around to recursive calls, subsequent (and generated) invocations, etc.)
3. It also future-proofs the plugin system (eg when contexts aren't provided in Macros 2.0).

To elaborate on the third, when contexts go away, the user is not guaranteed to even receive anything with a span on it (in the case that the macro's input is empty). To fix this, either the macro will need to take a span to use, take the whole invocation form as input (okay, but still, a macro writer have to get and thread spans around), or need some other way to get to these spans (TLS, I guess). If the expander takes care of this, however, none of this will ever become a concern.

[Mark-Simulacrum]

As far as I know nothing has been done related to this. @nrc @jseyfried This seems relevant to the macros 2.0 work, perhaps that will solve or help some of this?

[jyn514]

I'm not sure if this is still relevant - can proc macros still generate code with DUMMY_SP? How could I test it?

[petrochenkov]

It would be interesting to insert a check to AST -> HIR lowering to figure out what sources are dummy spans coming from in practice.

I think at least one legitimate source of dummy spans right now is prelude injection (and maybe proc macro harness and test harness injection).

If #84373 is merged, then we'll have a single point to place such check in - fn lower_span, but a commit introducing lower_span can be landed independently from whole #84373 if necessary.