absolute_paths can trigger on code produced by a macro

[ilyvion]

Summary

It looks like absolute_paths isn't properly "shielded" from macro code as something as simple as deriving serde::Deserialize on any type that holds another type with a generic sets it off.

Lint Name

absolute_paths

Reproducer

I tried this code:

use serde::Deserialize;

#[derive(Debug, Deserialize)]
struct Foo {
    bar: Vec<char>,
}

I saw this happen:

error: consider bringing this path into scope with the `use` keyword
 --> examples\min-repro.rs:9:5
  |
9 |     bar: Vec<char>,
  |     ^^^^^^^^^^^^^^
  |
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#absolute_paths
  = note: `-D clippy::absolute-paths` implied by `-D warnings`
  = help: to override `-D warnings` add `#[allow(clippy::absolute_paths)]`

error: consider bringing this path into scope with the `use` keyword
 --> examples\min-repro.rs:9:5
  |
9 |     bar: Vec<char>,
  |     ^^^^^^^^^^^^^^
  |
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#absolute_paths

I expected to see this happen:

Nothing, obviously. There are no absolute paths in non-macro generated code here.

Version

rustc 1.85.0-nightly (d117b7f21 2024-12-31)
binary: rustc
commit-hash: d117b7f211835282b3b177dc64245fff0327c04c
commit-date: 2024-12-31
host: x86_64-pc-windows-msvc
release: 1.85.0-nightly
LLVM version: 19.1.6

Additional Labels

No response

[Centri3]

It is.. I guess this is more procedural macros weirdness... Or this could very well be a bug in Path's implementation of WithSearchPat.

I see that TypeRelative doesn't check the beginning of the span, which might be why this happens.