>but the tool can't possibly know what the full relation between input and output is (because by definition the macro is an arbitrary function) The macro can a

>but the tool can't possibly know what the full relation between input and output is (because by definition the macro is an arbitrary function) The macro can associate output tokens with the spans of input tokens, either by reusing the input tokens (`#[derive(Foo)] struct S;` -> `impl Foo for S`, the `S` is reused), or using the macro API which allows specifying an arbitrary span for new tokens. This is required both for ident hygiene and for associating errors with the source code, thus it is a core part of the macro API. And since the compiler has this information, tools have it too. That means if you have #[foo] struct S; // (1) let s = S; // (2) and use an IDE to refactor-rename `S` to `S2` at the line marked (2), the IDE has enough information to know that it must also rename the `S` at the line marked (1), even though it's a macro input. This applies equally well to function-style proc macros `foo! { S }`