array impls <= 32 1.39 regression

[Mark-Simulacrum]

https://crater-reports.s3.amazonaws.com/beta-1.39-1/beta-2019-09-28/reg/duktape_ffi_raw-2.30.0/log.txt
https://crater-reports.s3.amazonaws.com/beta-1.39-1/beta-2019-09-28/gh/docteurklein.inotify-sse/log.txt

cc #61415

cc #64962

[scottmcm]

cc PR #62435 No, turns out that was in 1.38

[INFO] [stderr]   the trait `std::array::LengthAtMost32` is not implemented for `[i8; 128]`
[INFO] [stderr]   |
[INFO] [stderr]   = note: required because of the requirements on the impl of `std::fmt::Debug` for `[i8; 128]`
[INFO] [stderr]   = note: required because of the requirements on the impl of `std::fmt::Debug` for `&[i8; 128]`
[INFO] [stderr]   = note: required for the cast to the object type `dyn std::fmt::Debug`

I guess this used to unsize to a slice?

[bluss]

Formatting the first it points to this:

error[E0277]: arrays only have std trait implementations for lengths 0..=32
   --> src/lib.rs:362:5
    |
362 |     pub data: [::std::os::raw::c_char; 128usize],
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `std::array::LengthAtMost32` is not implemented for `[i8; 128]`
    |
    = note: required because of the requirements on the impl of `std::fmt::Debug` for `[i8; 128]`
    = note: required because of the requirements on the impl of `std::fmt::Debug` for `&[i8; 128]`
    = note: required for the cast to the object type `dyn std::fmt::Debug`

in

#[repr(C)]
#[derive(Debug, Copy, Clone)]
pub struct duk_thread_state {
    pub data: [::std::os::raw::c_char; 128usize],
}

And it fails to compile in Rust 1.37, 1.38 as well, so it's not a regression. Since this is generated code, it could be that it's a change in what code is being generated, but it seems unlikely?

[pnkfelix]

triage: P-high (at least to get to bottom of what actual bug is here)

[LukasKalbertodt]

I tried to investigate a bit. The problematic code:

#[repr(C)]
#[derive(Debug, Copy, Clone)]
pub struct duk_thread_state {
    pub data: [::std::os::raw::c_char; 128usize],
}

Does not compile in any compiler version after >1.0 (well, I only tested 1.30 -- 1.38, beta, nightly and 1.0, but I'm pretty sure that code was never accepted by the compiler).

This piece of code is generated by bindgen from a C library. The C library is part of the crate (i.e. it's not downloaded by the build script) and thus doesn't change. It can't be the reason for this breakage. So maybe bindgen changed its code generation? duktape_ffi_raw uses bindgen = "0.49.0", but there does not seem to be any relevant changes in the versions 0.49.0 to 0.49.3.

However, the other regression, libhydrogen-sys also uses bindgen to generate code. So it looks highly unlikely this is a spurious regression. libhydrogen-sys uses bindgen = "0" by the way (something that I luckily haven't seen before).

Maybe we could just ping someone from bindgen and ask them if something relevant changed?

[ecstatic-morse]

@LukasKalbertodt This is probably the same as the other bindgen-related regressions. According to @pcpthm in #65525:

Likely due to #64710 exposing bindgen bug rust-lang/rust-bindgen#1627. Updating bindgen fixes the issue.

I've not verified this, however.

[LukasKalbertodt]

I noticed something else: the documentation on docs.rs about the problematic struct of duktape_ffi_raw shows that Debug is not implemented for the struct. So the bindgen code generation did indeed change. At some point the Debug derive as not added, and thus the crate compiled fine. The regression is caused by derive(Debug) being added for some reason.

@ecstatic-morse I can't connect the bug you linked to what we are seeing here... but maybe it is indeed connected.

[tesuji]

I'm pretty sure that code was never accepted by the compiler

You're right. Tested on godbolt I came to the same conclusion: https://rust.godbolt.org/z/uS3ST2

[pcpthm]

Indeed it seems like another case of bindgen bug.
The bindgen bug affects the code-path of determining whether #[derive(Trait)] can be applied or not.
By default, bindgen applies #[derive(Debug)] whenever possible. The error matches the situation of when #[derive(Debug)] is applied to an underiveable struct, due to the bug.
Updating bindgen dependency should resolve the issue (though I'm not able to test this).

[pnkfelix]

assigning self to attempt to verify that this is fixed by upgrading bindgen