rustdoc shouldn't render deduced "unimpls" of auto traits as synthetic negative impls but simply not at all

[fmease]

Currently, when a given type doesn't impl an auto trait AutoTrait due to its constituents not impl'ing the auto trait, then rustdoc displays a synthetic negative impl of AutoTrait for said type. However, strictly speaking that's not correct as negative impls affect coherence and SemVer differently.

E.g., for:

pub struct Type(*const ());

rustdoc currently synthesizes

impl !Send for Type

to denote "Type doesn't impl Send" (due to <T: ?Sized> *const T: !Send). However that syntax is clashing with actual negative impls (presently unstably gated under negative_impls) which come with different SemVer guarantees (namely, "the type will never impl Send") and behave differently under coherence (for an example. see #146427).

Since synthetic auto trait impls are meant to be copy/paste-able into the source code w/o it affecting semantics (this principle is violated already, cc #111101), the simplest solution would be to stop synthesizing auto trait "unimpls".

I was worried that this isn't quite compatible with conditional negative impls (I might elaborate on that later) but they seem to get rejected anyway (time to update (parts of) #79098) with E0367. In any case, we might someday also have impl ?Trait for Type (Negative impls draft RFC § ? and auto-traits, #68318 (comment) et seqq.) which we could fall back to in case we ever need to express more complex bounds.

---

Originally reported in #146427 (comment) by @RReverser.

[fmease]

I was worried that this isn't quite compatible with conditional negative impls (I might elaborate on that later)

E.g., if the following code was allowed:

pub struct Outer<T>(Inner<T>);
struct Inner<T>(T);

impl<T: Bound> !AutoTrait for Inner<T> {} // (not allowed rn; E0367; cc #79098)

Then we obviously couldn't use the absence of an AutoTrait impl for Outer to denote that Outer<T> doesn't impl AutoTrait for all types T. We would need to render it as either

• impl<T: Bound> ?AutoTrait for Outer<T> (Negative impls draft RFC § ? and auto-traits, #68318 (comment) et seqq.) or as
• impl<T: !Bound> AutoTrait for Outer<T>, i.e., by flipping it around and using negative bounds (but it's unlikely that these ever become user-writable on stable)
  • I'm not sure if you can always do this transformation
    • like, outlives-bound would "need"¹ to be negatable as well (e.g., !'a) and
    • what about associated item bindings / equality constraints?
    • I haven't thought much about but I feel like this could get hairy fast
  • Actually, I don't think this would be correct because the !Bound bound would actually mean "the type impls Bound negatively" but we want to capture #[unimpled_or_negative] Bound

Footnotes

1. Wrt. "synthetic auto trait impls are meant to be copy/paste-able into the source code w/o it affecting semantics". ↩