false positive on chained re-exports of ffi C types with `disallowed-types` lint

Summary

I didn't find a corresponding issue before creating this, so sorry if this bug was already known.

Here is an example clippy.toml file:

disallowed-types = [
  { path = "core::ffi::c_int", replacement = "std::ffi::c_int" },
]

Even though in a reproducer example I use std::ffi::c_int (which is a replacement type, though correct one), it still creates a warning on a use of disallowed type.

I think, that is because of chained re-exports of each in std: core::ffi::c_int <-> std::ffi::c_int. Also, there is no such problem if we use std::os::raw::c_int (it seems it is not used in this re-export chain).

Lint Name

disallowed-types

Reproducer

I tried this code:

fn something() -> std::ffi::c_int { todo!() }

I saw this happen:

$ cargo clippy
warning: use of a disallowed type `core::ffi::c_int`
 --> src/main.rs:1:23
  |
1 | pub fn something() -> std::ffi::c_int { todo!() }
  |                       ^^^^^^^^^^^^^^^
  |
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#disallowed_types
  = note: `#[warn(clippy::disallowed_types)]` on by default

I expected to see this happen:
No warning should have happened.

Version

rustc 1.86.0 (05f9846f8 2025-03-31)
binary: rustc
commit-hash: 05f9846f893b09a1be1fc8560e33fc3c815cfecb
commit-date: 2025-03-31
host: x86_64-unknown-linux-gnu
release: 1.86.0
LLVM version: 19.1.7

Additional Labels

No response

Start with the disallowed-types configuration in clippy.toml and the reproducer in src/main.rs, then run cargo clippy to confirm the false positive for std::ffi::c_int. Trace how the lint resolves the chained re-exports between core::ffi::c_int and std::ffi::c_int; done means the replacement type no longer produces a warning while the disallowed type remains detected.