Allow specifying multiple bounds for same associated item, except in trait objects

[Jules-Bertholet]

Supersedes #143146, fixes #143143.

This PR proposes to stop enforcing E0719 in all contexts other than trait object types.

E0719 forbids constraining the same associated item twice within the same angle-bracket delimited associated item bound list (the … inside T: Trait<…>). For example, the following are forbidden:

Forbidden	Working alternative
T: Trait<Gat<u32> = u32, Gat<u64> = u64>	T: Trait<Gat<u32> = u32> + Trait<Gat<u64> = u64>
T: Iterator<Item = u32, Item = i32>	T: Iterator<Item = u32> + Iterator<Item = i32> (trivially false)
T: Iterator<Item = u32, Item = u32>	T: Iterator<Item = u32>
T: Iterator<Item: Send, Item: Sync>	T: Iterator<Item: Send + Sync>
T: Trait<ASSOC = 3, ASSOC = 4>	T: Trait<ASSOC = 3> + Trait<ASSOC = 4> (trivially false)
T: Trait<ASSOC = 3, ASSOC = 3>	T: Trait<ASSOC = 3>

With this PR, all those previously forbidden examples would start working, as well as their APIT and RPIT equivalents.

Types like dyn Iterator<Item = u32, Item = u32> will continue to be rejected, however. See #143146 (comment) for the reason why.

@rustbot label T-lang T-types needs-fcp

[rustbot]

HIR ty lowering was modified

cc @fmease

[fmease]

Nobody knows what E0719 is when they're just scrolling by and reading the title, it's as if you put a GH issue number there; please make the title more descriptive.

[BoxyUwU]

r? BoxyUwU

[traviscross]

Over in #143146, we had proposed FCP and then filed a concern related to dyn following @lcnr's comment in #143146 (comment). This PR removes the dyn part of this, so I'll go ahead and propose FCP again and check the boxes of those who had checked off there (@joshtriplett and @tmandry) as this is a strict subset of the other PR.

@rfcbot fcp merge

cc @rust-lang/types

[rust-rfcbot]

Team member @traviscross has proposed to merge this. The next step is review by the rest of the tagged team members:

• @joshtriplett
• @nikomatsakis
• @scottmcm
• @tmandry
• @traviscross

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

[traviscross]

@rfcbot ping

[rust-rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[bors]

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

[BoxyUwU]

Having two errors here seems unfortunate :( pre-existing though so no need to fix in this PR but it would be nice if it would be at some point

[BoxyUwU]

It feels weird to me that we would accept such code without linting on it, defining functions/ADTs/whatever that can never have their where clauses satisfied doesn't seem like the kind of thing people would want to intentionally do.

I would like us to add some unsatisfiable_bounds lint to detect this kind of case and warn people on it 🤔

[BoxyUwU]

@rust-lang/lang what are your thoughts on the fact that this PR causes us to accept this code without any lints:

trait Trait {
    type Assoc;
}

pub fn foo<T: Trait<Assoc = u32, Assoc = u64>>() {}

Here the function foo is uncallable as no type could possibly implement Trait such that both of those constraints on Assoc hold. We don't lint telling the user they've written an uncallable function. I think it would be nice to warn users when they've written an item that can never actually be used due to unsatisfiable where clauses.

Even though it was previously possibly to write T: Trait<Assoc = u32> + Trait<Assoc = u64> with the same behaviour, given we've explicitly gone out of our way here to accept more code like this it also seems like a good time to (re?)visit whether we want to lint on such code.

---

I think in theory this would have a types FCP, but given 3 of us already looked at the previous PR and don't anticipate any type system interactions here it seems perfectly fine to me to skip the FCP 👍 (especially since there's a t-types reviewer for this PR :3)

[traviscross]

@rust-lang/lang what are your thoughts on the fact that this PR causes us to accept this code without any lints:

...

I think it would be nice to warn users when they've written an item that can never actually be used due to unsatisfiable where clauses.

Even though it was previously possibly to write T: Trait<Assoc = u32> + Trait<Assoc = u64> with the same behaviour...

For my part, it doesn't change what I want to do here, but I'd be separately open to seeing a proposal for a lint that would flag both T: Tr<Ty = u32, Ty = u64> and T: Tr<Ty = u32> + Tr<Ty = u64>.

[rust-rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[BoxyUwU]

@bors r+

I think this is fine lang wise and we don't need to get Official:tm: sign off on this happening before some kind of lint. My understanding from the previous PR is that this also doesn't need any reference docs as we never documented this restriction in the first place :')

[bors]

📌 Commit 9f667cd has been approved by BoxyUwU

It is now in the queue for this repository.

[scottmcm]

@rfcbot reviewed

I agree that if we can write it in the other form anyway we might as well just accept this.

I also agree with @BoxyUwU that this seems like a place where it might be interesting to lint, but I don't think the PR needs to be blocked on that. (Indeed, I'd generally rather it not be the same PR for separation of concern reasons.)

[nikomatsakis]

@rfcbot reviewed