Lints stop firing if macro reports with `Span::call_site`? about rust HOT 4 OPEN

honestly the main reason this issue was opened is because it seems like the only reason that this would vary so much is a serious bug in the linting framework.

from rust.

wait, am I supposed to be writing Span::call_site().located_at(source_span) to point the error at the source while making the span aware it is a "macro-tainted" span? doing that seems to cause the lints to stop firing...

from rust.

honestly the main reason this issue was opened is because it seems like the only reason that this would vary so much is a serious bug in the linting framework.

IIRC, many lints don't try to handle macro-generated code (or code with mixed soures) because it's a lot of complexity. The lints typically use Span::from_expansion to check if a span is macro-generated, and assumes that spans generated from proc macros properly account for hygiene. In this case, I think you need Span::mixed_site().located_at(user_span) in order for the span to be marked as "generated from macros" (from your proc macro) so lints can avoid firing on macro-generated spans.

from rust.

for note, just using Span::call_site, without redirecting the span to its source in some way, can result in the span just touching a single character in an obviously-illogical way, which can be quite vexing. I think this is a consequence mostly of nested proc macro expansions? -Zmacro-backtrace doesn't really illuminate this much, as far as I've noticed.

from rust.