the trait bound `&[u8]: std::convert::From<&[_; 0]>` is not satisfied

[Mark-Simulacrum]

• https://crater-reports.s3.amazonaws.com/beta-1.71-4/beta-2023-06-25/gh/bchallenor.firebreak/log.txt
• https://crater-reports.s3.amazonaws.com/beta-1.71-4/beta-2023-06-25/reg/kresp-0.1.2/log.txt
• https://crater-reports.s3.amazonaws.com/beta-1.71-4/beta-2023-06-25/gh/AustinHaugerud.bextract/log.txt
• multiple impls satisfying [f32; 3]: From<_> found in the core crate
  • https://crater-reports.s3.amazonaws.com/beta-1.71-4/beta-2023-06-25/gh/Maxeonyx.terrain-viewer/log.txt
  • possibly related?

[hameerabbasi]

This seems to already have been fixed on the main branch and also on cca7ee5 (which is what I get if I run cargo-bisect-rustc with the HEAD of the beta branch).

[compiler-errors]

@hameerabbasi how did you build this? You need to build all the tests to reproduce this, too.

[compiler-errors]

This seems to have regressed in #106704. From the UI test at the bottom of that PR, it seems to suggest that we've added a new &[u8]: From<gimli::read::endian_slice::EndianSlice<'_, Endian>>> implementation, which may have affected the inference/coercion somewhere in that program.

[Mark-Simulacrum]

Seems plausible, and seems like that trait impl might be removable - though maybe a breaking change for gimli?

[cuviper]

This is reproducible on stable if gimli 0.27.* is pulled in at all:

extern crate gimli;
fn main() {
    let _ = <&[u8]>::from(&[]);
}

error[E0277]: the trait bound `&[u8]: From<&[_; 0]>` is not satisfied
 --> src/main.rs:3:27
  |
3 |     let _ = <&[u8]>::from(&[]);
  |             ------------- ^^^ the trait `From<&[_; 0]>` is not implemented for `&[u8]`
  |             |
  |             required by a bound introduced by this call
  |
  = help: the trait `From<EndianSlice<'input, Endian>>` is implemented for `&'input [u8]`

But now that std is pulling that version of gimli, everyone gets to feel the pain. Without that impl, &[u8] would only have the reflexive From, driving the &[] into an unsizing coercion. An uncoerced From<&[T; N]> for &[T] seems totally plausible though - I wonder if we've tried that before? (It's way too late to add new impls to 1.71 though.)

seems like that trait impl might be removable - though maybe a breaking change for gimli?

I didn't look into how it's used, but EndianSlice is a public type, so yes that would be breaking to remove it.

Reverting #106704 is going to be hard too, because the new gimli is coming from backtrace (submodule in std) -> addr2line 0.19 -> gimli 0.27, and there are other backtrace updates that I expect we want to keep.

[cuviper]

Hmm, actually it seems to build ok if I just downgrade to addr2line 0.18 (which also drops to gimli 0.26) here:

rust/library/std/Cargo.toml

Line 26 in f06c1b8

addr2line = { version = "0.19.0", optional = true, default-features = false }

So I guess it doesn't really need APIs of the newer version, but I don't know if we'll miss fixes or functionality. I can PR this as a release band-aid if others agree that it makes sense...

[Mark-Simulacrum]

Hm, I think some folks have been more actively poking at backtrace lately, I don't know what we'd lose by downgrading there - cc @rust-lang/crate-maintainers (broader group but hopefully reaches the right people).

I guess the question is: are we comfortable downgrading addr2line as suggested by @cuviper for 1.70 (releasing next week)?

[Noratrieb]

What's the plan for the future? I don't think we want to stay on old gimli forever. Hope that gimli removes the impl in a breaking release, which we could then pull in?

[cuviper]

So I guess it doesn't really need APIs of the newer version,

Actually, there were no API changes in addr2line 0.18 to 0.19, only the dependency changes:
gimli-rs/addr2line@0.18.0...0.19.0

for 1.70 (releasing next week)?

That's 1.71.0.

What's the plan for the future?

Unknown. I can see if adding From<&[T; N]> for &[T] is actually feasible, but it's possible that this may introduce other ambiguities. Another (hacky) possibility is to get gimli to only remove that impl under its "rustc-dep-of-std" feature, since they document this feature as not part of their stable API, assuming any internal use can be converted to other means.