`expected a type, found an import` warning false positive of "disallowed-types"

[ldm0]

Summary

"disallowed-types"'s false positive

Lint Name

disallowed-types

Reproducer

Minimal reproduction: https://github.com/ldm0/rust_test2

cargo clippy -p foo

I saw this happen:

warning: expected a type, found an import
 --> /Users/ldm0/repo/tmp/rust_test3/clippy.toml:2:5
  |
2 |     { path = "foo::Fooo", reason = "Noooooooooo" },
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

warning: `foo` (lib) generated 1 warning
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.01s

I expected to see no warning emitted.

Version

rustc 1.88.0-nightly (cb31a009e 2025-04-27)
binary: rustc
commit-hash: cb31a009e3e735ab08613cec2d8a5a754e65596f
commit-date: 2025-04-27
host: aarch64-apple-darwin
release: 1.88.0-nightly
LLVM version: 20.1.2

Additional Labels

No response

[samueltardieu]

Why would you put something in disallowed-types in the first place if you don't want do disallow it?

[ldm0]

Why would you put something in disallowed-types in the first place if you don't want do disallow it?

In reality, we have a large workspace where foo is a library in it. And we don't want other crates in this workspace to depend on some types of foo. So we put them in disallowed-types. The problem is that foo itself emits strange warning(described in this issue).

[smoelius]

@ldm0 Suppose adding #![allow(clippy::disallowed_types)] to foo/src/lib.rs made the warning go away. (It currently doesn't, but if it did...) Do you think that would solve the problem for your actual workspace?

[Alexendoo]

The issue is that it's not resolving through the re-export, that can be fixed directly

For the meantime path = "foo::fooo::Fooo should work