Span::resolved_at and Span::located_at to combine behavior of two spans

[dtolnay]

Added upstream in rust-lang/rust#47149.

Proc macro spans serve two mostly unrelated purposes: controlling name resolution and controlling error messages. It can be useful to mix the name resolution behavior of one span with the line/column error message locations of a different span.

In particular, consider the case of a trait brought into scope within the def_site of a custom derive. I want to invoke trait methods on the fields of the user's struct. If the field type does not implement the right trait, I want the error message to underline the corresponding struct field.

Generating the method call with the def_site span is not ideal -- it compiles and runs but error messages sadly always point to the derive attribute like we saw with Macros 1.1.

  |
4 | #[derive(HeapSize)]
  |          ^^^^^^^^

Generating the method call with the same span as the struct field's ident or type is not correct -- it shows the right underlines but fails to resolve to the trait in scope at the def_site.

  |
7 |     bad: std::thread::Thread,
  |     ^^^^^^^^^^^^^^^^^^^^^^^^

The correct span for the method call is one that combines the def_site's name resolution with the struct field's line/column.

field.span.resolved_at(Span::def_site())

// equivalently
Span::def_site().located_at(field.span)

Adding both because which one is more natural will depend on context.

[dtolnay]

Examples of use: heapsize_derive and lazy-static.

[mystor]

Nice! Those demos are pretty awesome looking :-)

[alexcrichton]

Looks great! Should these be behind the line/column same feature gate? Or are these too important to pass up?

[dtolnay]

I don't think these should be feature gated. Unlike Span::join and Span::source_file and the various custom error APIs, these are something I believe we need to build strong best practices around from the beginning. If these eventually change, I would see that as important enough to do a major version of proc-macro2 (again, unlike something like Span::source_file).

[alexcrichton]

Sounds good to me!