Emit warning when bound is trivially false

[compiler-errors]

We really should be rejecting bounds that are global, even if they have higher-ranked lifetimes. We have the ability to prove whether for<'a> &'a mut String: Clone is true or not, so there's no reason to silently allow this to typecheck, especially because it's inconsistent with a non-HRTB like &'static mut String: Clone and is the source of ICEs.

For now, though, just add a warning, so that when an ICE does occur (because sometimes it will), then the user knows what might've caused it.

This is a revival of #95611.

[rust-highfive]

r? @petrochenkov

(rust-highfive has picked a reviewer for you, use r? to override)

[compiler-errors]

r? types

[jackh726]

Let's specifically r? @nikomatsakis, since he has some specific thoughts on this :)

(Though I personally do think a warning is good)

[jackh726]

Warnings here...aren't great.

[jackh726]

It's a bit unfortunate that the bound we say is not the bound that's written.

[jackh726]

This is certainly not great.

[bors]

☔ The latest upstream changes (presumably #100676) made this pull request unmergeable. Please resolve the merge conflicts.

[QuineDot]

We really should be rejecting bounds that are global, even if they have higher-ranked lifetimes.

As per RFC 2056, they should not be rejected. The HRTB's this targets can currently be used to achieve trivial bounds without #[feature(trivial_bounds)]. The motivating example in that comment is the inability to omit unsatisfiable trait members, i.e. it works around a practical problem. Until true trivial bounds are allowed on stable, it's arguably a more sensible workaround than leaving the bound off entirely -- especially once such a refined implementation can in other cases be called / relied upon.

Warning makes sense though.

[nikomatsakis]

I agree with warning, but I feel strongly that we should not be rejecting where-clauses that are known to be false. As @QuineDot noted, RFC 2056 decided against it, and I think that is well motivated.