Nonsensical error message with const generics and std::mem::sized_of

[Aaron1011]

The following code:

#![feature(const_generics)]

trait IsZst {
    type ZST;
}

impl<T: Sized> IsZst for T where T: Sized {
    type ZST = ZstHelper<{std::mem::size_of::<T>() == 0}>;
}

struct ZstHelper<const T: bool>;

produces the following error:

error[E0277]: the size for values of type `T` cannot be known at compilation time
 --> src/lib.rs:8:27
  |
8 |     type ZST = ZstHelper<{std::mem::size_of::<T>() == 0}>;
  |                           ^^^^^^^^^^^^^^^^^^^^^^ doesn't have a size known at compile-time
  |
  = help: the trait `std::marker::Sized` is not implemented for `T`
  = note: to learn more, visit <https://doc.rust-lang.org/book/ch19-04-advanced-types.html#dynamically-sized-types-and-the-sized-trait>
  = help: consider adding a `where T: std::marker::Sized` bound
  = note: required by `std::mem::size_of`

despite the fact that we have that T: Sized. If there's another reason why this code shouldn't compile, the error message should clearly state it.

[the8472]

I have run into this issue several times, here's a case I wouldn't even consider const generics, it is a const eval problem in a generic context instead

const fn batch_size<T: Sized>() -> usize {
    32 / std::mem::size_of::<T>()
}

fn x<T: Sized>() {
    [1; batch_size::<T>()];
}

error[E0277]: the size for values of type `T` cannot be known at compilation time
 --> src/main.rs:9:22
  |
4 | const fn batch_size<T: Sized>() -> usize {
  |          ---------- - required by this bound in `batch_size`
...
8 | fn x<T: Sized>() {
  |      -- help: consider further restricting this bound: `T: std::marker::Sized +`
9 |     [1; batch_size::<T>()];
  |                      ^ doesn't have a size known at compile-time
  |

[golddranks]

This seems to have been fixed on the new nightlies: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=16495147fbcdd34da629b2ee40e6072b

[comex]

Cool! Although if I extend your example to actually test the associated type:

fn needs_zst<T>(_: T) where T: IsZst<ZST=ZstHelper<{true}>> {}

I get some nice errors:

error[E0391]: cycle detected when const-evaluating + checking `needs_zst::{{constant}}#0`
  --> src/lib.rs:13:52
   |
13 | fn needs_zst<T>(q: T) where T: IsZst<ZST=ZstHelper<{true}>> {}
   |                                                    ^^^^^^
   |
note: ...which requires const-evaluating + checking `needs_zst::{{constant}}#0`...
  --> src/lib.rs:13:52
   |
13 | fn needs_zst<T>(q: T) where T: IsZst<ZST=ZstHelper<{true}>> {}
   |                                                    ^^^^^^
note: ...which requires const-evaluating `needs_zst::{{constant}}#0`...
  --> src/lib.rs:13:52
   |
13 | fn needs_zst<T>(q: T) where T: IsZst<ZST=ZstHelper<{true}>> {}
   |                                                    ^^^^^^
note: ...which requires processing `needs_zst::{{constant}}#0`...
  --> src/lib.rs:13:52
   |
13 | fn needs_zst<T>(q: T) where T: IsZst<ZST=ZstHelper<{true}>> {}
   |                                                    ^^^^^^
note: ...which requires processing `needs_zst::{{constant}}#0`...
  --> src/lib.rs:13:52
   |
13 | fn needs_zst<T>(q: T) where T: IsZst<ZST=ZstHelper<{true}>> {}
   |                                                    ^^^^^^
   = note: ...which again requires const-evaluating + checking `needs_zst::{{constant}}#0`, completing the cycle
note: cycle used when processing `needs_zst`
  --> src/lib.rs:13:1
   |
13 | fn needs_zst<T>(q: T) where T: IsZst<ZST=ZstHelper<{true}>> {}
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[Aaron1011]

The cycle appears to be due to eger normalization when constructing the ParamEnv during wf-checking of the impl.

[the8472]

The example in OP now gets the cycle error, but my case still fails with the nonsensical one.

[ExpHP]

Isn't this just a duplicate of #43408?

(I mean, yeah, that issue is about this not working, while this issue is about the terrible error message; but many of the closed duplicates are also about the error message. The fact that this error message is still here gives me the impression that fixing the message must be as difficult as making it compile!)

[Dylan-DPC-zz]

I agree with @ExpHP here, since when those issues are fixed the error message is going to change. Closing this as duplicate.