Diagnostics sometimes suggest items from `rustc_private` crates

[tgross35]

Code

This requires a compiler_builtins that includes a public or possibly public (i.e. feature gated) trait. The most recent v0.1.142 has this on Windows only (attempted update in #135180), I have a patched branch that makes this trait available on all platforms https://github.com/tgross35/rust/tree/experiment-builtins-math.

trait Trait { type Bar; }
type Foo = dyn Trait<F = i32, Bar = i32>;

Current output

Running rustc +stage0 foo.rs --crate-type=lib

--> foo.rs:6:22
  |
6 | type Foo = dyn Trait<F = i32, Bar = i32>;
  |                      ^ there is a similarly named associated type `H` in the trait `compiler_builtins::math::libm::support::int_traits::DInt`

Desired output

Don't suggest using compiler_builtins unless the crate is #![feature(rustc_private)]

Rationale and extra context

My investigation on Zulip https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/Why.20do.20diagnostics.20suggest.20compiler_builtins

Rust Version

Current stage0

rustc 1.84.0-beta.1 (b4297a573 2024-11-26)
binary: rustc
commit-hash: b4297a573b4eefacd62e7ea1ba071536282d3254
commit-date: 2024-11-26
host: x86_64-unknown-linux-gnu
release: 1.84.0-beta.1
LLVM version: 19.1.4

Anything else?

No response

[tgross35]

The context is that compiler_builtins has a lot of traits that are usually private but are public with a feature for testing. Currently everything is wrapped in a cfged macro so the traits don't even make it to AST unless the relevant config is enabled. It would be much nicer to instead just make the relevant module conditionally private/public, but since diagnostics ignore module visibility, that means they can show up in diagnostics if the crate is accessible.

I did try making that change before rust-lang/compiler-builtins#656, which had to be reverted because of the failure at #128691 (comment). Didn't look into the cause too much at that time. But in any case, the current situation isn't very robust, and finding problems only at sync time is inconvenient.

I can try to figure this out but I'm not sure where to start. @compiler-errors this seems like your territory, any suggestions?

[tgross35]

Also this only seems to apply to trait-related diagnostics, e.g. calling a function from compiler_builtins doesn't suggest anything.

fn main() {
    __adddf3(1.0, 2.0);
}

[tgross35]

More reliable repro that works on stable and refers to addr2line from the sysroot

trait Trait { type Bar; }
type Foo = dyn Trait<Buf = i32, Bar = i32>;

error[E0220]: associated type `Buf` not found for `Trait`
 --> src/lib.rs:2:22
  |
2 | type Foo = dyn Trait<Buf = i32, Bar = i32>;
  |                      ^^^ there is an associated type `Buf` in the trait `addr2line::LookupContinuation`

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=f137a5a714aff5759deb28283947f9c6

Looks like this might be easier than expected if this is the only kind of error, maybe just a filter at

rust/compiler/rustc_hir_analysis/src/hir_ty_lowering/errors.rs

Lines 201 to 209 in 0707499

	if let [best_trait] = visible_traits
	.iter()
	.copied()
	.filter(|trait_def_id| {
	tcx.associated_items(trait_def_id)
	.filter_by_name_unhygienic(suggested_name)
	.any(|item| item.kind == assoc_kind)
	})
	.collect::<Vec<_>>()[..]

.