Warn about more ignored bounds in type aliases

[RalfJung]

It seems that all bounds in type aliases are entirely ignored, not just type bounds. This extends the warning appropriately.

I assume this should be made a hard error with the next epoch? I can't see any reason to accept these programs. (And suddenly enforcing these type bounds would be a breaking change.)

[rust-highfive]

r? @petrochenkov

(rust_highfive has picked a reviewer for you, use r? to override)

[petrochenkov]

Nit: maybe "generic bounds" instead just "bounds"?
Just "bounds" looks like something is missing to me. Not sure.

[petrochenkov]

r=me after maybe fixing the nit
@bors delegate+

[bors]

✌️ @RalfJung can now approve this pull request

[RalfJung]

Oh fancy, I had no idea bors supports delegation like this. oO

I didn't want to write "type and lifetime bounds", hence my choice of words. I like "generic bounds", thanks for the suggestion!

[RalfJung]

@bors r=@petrochenkov

Let's see if this works...

[bors]

📌 Commit ac183f8 has been approved by @petrochenkov

[RalfJung]

Oh, seems like you don't usually put at @ after r=... is that a problem?

[petrochenkov]

@RalfJung
IIUC, the right side of @bors r= is for humans only and can contain anything if the comment author has r+ rights.

[bors]

💡 This pull request was already approved, no need to approve it again.

• There's another pull request that is currently being tested, blocking this pull request: correct unused field pattern suggestions #47922

[bors]

📌 Commit ac183f8 has been approved by petrochenkov

[bors]

💡 This pull request was already approved, no need to approve it again.

• There's another pull request that is currently being tested, blocking this pull request: correct unused field pattern suggestions #47922

[bors]

📌 Commit ac183f8 has been approved by ```

[RalfJung]

lol indeed. Now poor bors is confused. Also, does it escape things properly? What about r=<!-- foobar -->? ;)

@bors r=petrochenkov

[bors]

💡 This pull request was already approved, no need to approve it again.

• There's another pull request that is currently being tested, blocking this pull request: correct unused field pattern suggestions #47922

[bors]

📌 Commit ac183f8 has been approved by petrochenkov

[bors]

💡 This pull request was already approved, no need to approve it again.

• There's another pull request that is currently being tested, blocking this pull request: correct unused field pattern suggestions #47922

[bors]

📌 Commit ac183f8 has been approved by petrochenkov

[bluss]

Just to be on the safe side, if you propose making it an error, what will happen to code like this, will it continue to be accepted?:

use std::ops::Index;typeOutput<I,T> = <IasIndex<T>>::Output;

[RalfJung]

I think so -- this checks bounds in the binders of type aliases, not touching the code it expands to. I assume you bring this up because it actually works? All I'm advocating for is the compiler tell us when we write something that it doesn't support.

[bluss]

Yes it works, but my intuition would be that the bound is required in the type alias definition there, and the compiler is doing the opposite, enforcing the form without bound.

[RalfJung]

The current behavior of type aliases is essentially a syntactic expansion. It's more like a macro. Type bounds are checked later. (That's my interpretation anyway, please correct me if that's wrong.)

I do agree that this is somewhat unexpected. However, changing it is backwards-incompatible. So I figured we could at least try to reduce the confusion by telling people when we ignore what they write, e.g. if they do

type SendableVec<T: Send> = Vec<T>

which actually doesn't mean the Vec is sendable.

I suppose what you're saying is that instead of forcing (well, linting) the bounds to be empty, we could lint them to exactly match whatever is required to make sense of the type in the right? I agree that'd be somewhat nicer and more compatible with an eventual future where these bounds are actually checked (at def'n time) and enforced. Unfortunately, I have no idea how to go about implementing that; it seems pretty complicated. Do you think this is a realistic thing to do, and we should rather abort/revert this MR to not have people that want to adhere to the lint change their code twice?

Notice however that for type bounds, we already warn. This just adds the same warning to lifetime bounds.

[bluss]

In the long run I think the bound requirement is correct, but this has already turned quite the other way (with regular bounds), so it doesn't matter to stop just this PR.