Array lengths don't support generic parameters.

[roblabla]

EDIT: This can now be made to work on nightly compilers, although it's a bit awkward to use. See this comment.

It would seem that when using size_of in const fn context, it fails to properly compute the size of generic types.

The following function fails

unsafe fn zeroed<T: Sized>() -> T {
    // First create an array that has the same size as T, initialized at 0
    let x = [0u8; std::mem::size_of::<T>()];
    // Then, transmute it to type T, and return it
    std::mem::transmute(x)
}

The error is the following :

error[E0277]: the trait bound `T: std::marker::Sized` is not satisfied
 --> src/main.rs:3:19
  |
3 |     let x = [0u8; std::mem::size_of::<T>()];
  |                   ^^^^^^^^^^^^^^^^^^^^^^ `T` does not have a constant size known at compile-time
  |
  = help: the trait `std::marker::Sized` is not implemented for `T`
  = help: consider adding a `where T: std::marker::Sized` bound
  = note: required by `std::mem::size_of`

This is very confusing because it complains that T doesn't have std::marker::Sized, even though it does have that bound.

Meta

rustc_version : rustc 1.20.0-nightly (ae98ebf 2017-07-20)

[Mark-Simulacrum]

cc @eddyb -- was this intentional?

[eddyb]

This is a limitation of array length - it can't use any parameters in scope - which also came up during the stabilization of associated consts (cc @withoutboats do we have a common issue to use for this?) and the decision taken was to stabilize associated consts without it.

The exact error here comes from the type parameter being resolved, but the ty::Generics and ty::GenericPredicates (bounds, including the default Sized on type parameters) of the array length are actually both empty. They have to be (for now), otherwise we get cycle errors.

[eddyb]

This example triggers a const-evaluation error instead (try on playpen):

fn test<T: ?Sized>() {
    [0u8; std::mem::size_of::<&T>()];
}

cc @GuillaumeGomez @oli-obk Why is the const-eval error printing broken still 😢?

[scottmcm]

This makes me sad, as it's the one thing I wanted to do with #42859 😢

[juchiast]

I think we shoud change the error message, this is very confusing now.

[eddyb]

@ExpHP The problem is using type parameters (e.g. your T) in array lengths, everything else works.

@juchiast The error message is "emergent" from the same reason we can't "just" allow this to work right now, the the only other solution I can think of is checking if type-parameters are "really in scope" but that would probably break existing code that doesn't need to look at type parameters.

[MageSlayer]

#![feature(const_fn)]
pub const fn sof<T:?Sized>() -> usize {
    10
}
fn to_byte_array<T>() -> [u8; sof::<T>()] {
     panic!()
}

Trying this way results in compiler crash in nightly.

error: internal compiler error: librustc/ty/subst.rs:456: Type parameter `T/#0` (T/0) out of range when substituting (root type=Some(fn() -> usize {sof::<T>})) substs=[]

thread 'main' panicked at 'Box<Any>', librustc_errors/lib.rs:499:9

Any workarounds known?

[eddyb]

@MageSlayer Nope, it just can't be supported yet, see #43408 (comment) and previous.

[JohnTitor]

Triage:

The current output of #43408 (comment) with the latest nightly:

error: generic parameters may not be used in const operations
 --> src\main.rs:7:37
  |
7 | fn to_byte_array<T>() -> [u8; sof::<T>()] {
  |                                     ^ cannot perform const operation using `T`
  |
  = note: type parameters may not be used in const expressions
  = help: use `#![feature(const_generics)]` and `#![feature(const_evaluatable_checked)]` to allow generic const expressions

error: aborting due to previous error

And with #![feature(const_generics)]:

warning: cannot use constants which depend on generic parameters in types
 --> src\main.rs:8:30
  |
8 | pub fn to_byte_array<T>() -> [u8; sof::<T>()] {
  |                              ^^^^^^^^^^^^^^^^
  |
  = note: `#[warn(const_evaluatable_unchecked)]` on by default
  = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!        
  = note: for more information, see issue #76200 <https://github.com/rust-lang/rust/issues/76200>

It's no longer ICE but rejected by const_evaluatable_checked.

[roblabla]

This now appear to work-ish, but is a bit awkward to use:

#![feature(generic_const_exprs)]

unsafe fn zeroed<T: Sized>() -> T 
where
    [(); std::mem::size_of::<T>()]:
{
    // First create an array that has the same size as T, initialized at 0
    let x = [0u8; std::mem::size_of::<T>()];
    // Then, transmute it to type T, and return it
    std::mem::transmute_copy(&x)
}

Two things of note:

• The weird where close with an empty bound is necessary, otherwise I get an error: unconstrained generic constant.
• Transmute doesn't work, because the compiler fails to prove that [u8; size_of::<T>()] has the same size as T, so we have to work around this by using transmute_copy

[roblabla]

Though not relevant to the compiler issue, for the sake of those who may come across this it is obligatory to point out that the above implementation of zeroed using std::mem::transmute_copy can invoke UB if std::mem::align_of::<T>() > 1, which is likely not the intent.

@ExpHP I believe this is wrong, and my implementation is safe even if T has a higher alignment than 1. Heres what transmute_copy's documentation says:

This function will unsafely assume the pointer src is valid for size_of::<U> bytes by transmuting &T to &U and then reading the &U (except that this is done in a way that is correct even when &U makes stricter alignment requirements than &T). It will also unsafely create a copy of the contained value instead of moving out of src.

(Emphasis mine)

I believe this means that it is correct even when &U (our output type) has a "stricter alignment" (higher alignment) than &[u8]. If this is wrong, then I think the documentation of transmute_copy should be changed to better define what stricter alignment means.

[agausmann]

@roblabla is right, transmute_copy uses std::ptr::read_unaligned internally, which will safely read the value of unaligned pointers, and the destination of the copy will be at an aligned location in memory.

The docs for transmute_copy are sort of incorrect though. It never transmutes &T to &U, it obtains an unaligned pointer *const U by casting src as *const T as *const U, which it then reads using read_unaligned. If it ever did create an unaligned reference &U, then it would be UB, but it does not.

[estebank]

Follow up to #43408 (comment)

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=ffb92ec39b7481bfd1b3f435257ed3ce now works by changing the feature

[Enselic]

It's no longer ICE

@rustbot label -I-ICE