You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Rollup merge of rust-lang#47149 - dtolnay:spans, r=jseyfried
Span::resolved_at and Span::located_at to combine behavior of two spans
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.
```rust
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.
Addresses rust-lang#38356 (comment). r? @jseyfried
0 commit comments