Type alias fails to produce a type error for unsized type

[bstrie]

Here's a program that we expect to fail to compile, and happily it does fail to compile:

trait Foo {}
struct Bar(Vec<Foo>);  // uh-oh
fn main() {}

Here's the happy error message:

error[E0277]: the trait bound `Foo + 'static: std::marker::Sized` is not satisfied
 --> src/main.rs:2:12
  |
2 | struct Bar(Vec<Foo>);
  |            ^^^^^^^^^ `Foo + 'static` does not have a constant size known at compile-time
  |
  = help: the trait `std::marker::Sized` is not implemented for `Foo + 'static`
  = note: required by `std::vec::Vec`

Here's the actual bug: if we use a type alias here rather than a newtype, this does not fail to compile:

trait Foo {}
type Bar = Vec<Foo>;  // compiles!
fn main() {}

Fortunately it appears to be impossible to actually instantiate this, but surely this should fail to compile just as the first example does.

[bstrie]

While mentioning this on IRC @thepowersgang noted that mrustc deliberately doesn't typecheck type alias declarations because it encountered unexpected compilation failures while testing against crates.io. I'm still hopeful that such an invalid declaration would be impossible to instantiate, but it's possible that the failures mrustc encountered were more insidious than the simple test case here. Because of this discovery, nominating for discussion based on the backcompat hazard this might present.

[thepowersgang]

Note for the above - The failing code was along the lines of type Foo<T> = RequiresSomeTrait<T>; - which failed when trait bounds were checked.

[petrochenkov]

From RFC 1214:

Unresolved questions

Best policy for type aliases. The current policy is not to check
type aliases, since they are transparent to type-checking, and hence
their expansion can be checked instead. This is coherent, though
somewhat confusing in terms of the interaction with projections, since
we frequently cannot resolve projections without at least minimal
bounds (i.e., type IteratorAndItem<T:Iterator> = (T::Item, T)). Still, full-checking of WF on type aliases seems to just mean
more annotation with little benefit. It might be nice to keep the
current policy and later, if/when we adopt a more full notion of
implied bounds, rationalize it by saying that the suitable bounds for
a type alias are implied by its expansion.

[bstrie]

Interesting. RFC 1214 is tracked at #27579, would be good to know if there's any more clarity since 2015 on how we ought to be handling this.

[michaelwoerister]

Discussed during compiler triage. We are closing this as a duplicate of #44075. Thanks, @bstrie!