Rust thread questions trait-level control over diagnostics recommendations

A Rust Internals thread on July 2 asked whether `#[diagnostic::do_not_recommend]` should move from impls to traits, after a Linux kernel case showed rustc steering a developer toward `IdTable` when `&DmaBuf` was missing `as_ptr`. The thread drew 5 replies and 459 views shortly after posting, a sign that the question landed well beyond a narrow attribute tweak.

The current rules make the limitation easy to see. The Rust Reference says `diagnostic::do_not_recommend` is meant to keep the compiler from showing a trait implementation in error messages, while nightly rustc’s `MISPLACED_DIAGNOSTIC_ATTRIBUTES` lint says the attribute can only be placed on trait implementations and does nothing elsewhere. Rust’s diagnostic attribute docs also separate it from `on_unimplemented`, which is aimed at trait-not-implemented errors. In practice, that leaves authors with a blunt tool when rustc finds a trait in scope but recommends it at exactly the wrong moment.

That is what made the Linux kernel example sting. The compiler’s diagnostic did not merely note a missing method on `&DmaBuf`; it offered a generic `IdTable` trait that was technically available but not actually the fix. The argument in the thread was that this is not a naming problem, but a recommendation problem: if the compiler knows enough to surface the trait, it does not always know enough to know that the hint will mislead. Expanding `#[diagnostic::do_not_recommend]` to the trait declaration, or even to individual methods, would let authors suppress the bad suggestion closer to the source instead of working around it elsewhere.

The replies showed the same pressure from another corner of the language. One participant said the issue was a blocker for PR #146381, “Generalize `impl<T> Clone for Box<T>` to unsized types.” Another Rust team member answered, “I'm fully supportive of this addition. The hardest part would be finding all of the places where the do_not_recommend should be followed.” The thread also fit into broader compiler work already underway in rust-lang/rust, including issue #125231, where `#[diagnostic::do_not_recommend]` was mentioned as a possible path in diagnostic design.

That is what made the question feel bigger than a small attribute adjustment. In code like the Linux kernel, where a wrong suggestion can send debugging sideways, the value is not in more diagnostics but in better ones, and this thread argued that Rust may need trait-level control to get there.