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

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?

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).

@hameerabbasi

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

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.

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

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.

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...

@cuviper

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)?

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?

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.

@Mark-Simulacrum

@Mark-Simulacrum The backtrace crate is going to need that gimli and object to be capable of later supporting AIX and also probably more recent platforms as well, as some object fixes were fixing platforms like watchOS. And it needs that gimli and addr2line to support the new DWARF formats which finally allow split debuginfo so we can maybe finally not have every Rust program be a hugely bloated binary on Linux and other Unix-y platforms.

Downgrading is an acceptable hotfix for stopping a regression from hitting stable, not for the long term.

@rustbot

WG-prioritization assigning priority (Zulip discussion).

@rustbot label -I-prioritize +P-high

Visited during T-compiler's weekly triage meeting. While this doesn't seem to be strictly under our purview, we are a bit concerned that the 1.72 release is coming up and this doesn't seem to have been mitigated in 1.72 yet.

Personally, I think if gimli is willing to remove the impl and ship a new major release (and coordinate that into a new addr2line release) that seems like the best medium term option. We may already be too late in the beta release cycle for that though so perhaps backporting the addr2line downgrade to 1.72 to ensure this regression does not accidentally get released makes sense?

Downgrade addr2line

@philipc

@philipc thanks for gimli-rs/gimli#669. Are you planning to make a release? (with addr2line as well if semver bumped)

We need to figure out the mitigation on 1.72-beta soon, but a downgrade to addr2line 0.18 doesn't work this time:

error[E0432]: unresolved imports `addr2line::LookupContinuation`, `addr2line::LookupResult`
   --> library/std/src/../../backtrace/src/symbolize/gimli.rs:163:25
    |
163 |         use addr2line::{LookupContinuation, LookupResult};
    |                         ^^^^^^^^^^^^^^^^^^  ^^^^^^^^^^^^ no `LookupResult` in the root
    |                         |
    |                         no `LookupContinuation` in the root

error[E0412]: cannot find type `SplitDwarfLoad` in crate `addr2line`
   --> library/std/src/../../backtrace/src/symbolize/gimli/elf.rs:461:22
    |
461 |     load: addr2line::SplitDwarfLoad<EndianSlice<'data, Endian>>,
    |                      ^^^^^^^^^^^^^^ not found in `addr2line`

error[E0599]: no method named `make_dwo` found for struct `Dwarf` in the current scope
   --> library/std/src/../../backtrace/src/symbolize/gimli/elf.rs:488:27
    |
488 |                 dwo_dwarf.make_dwo(&load.parent);
    |                           ^^^^^^^^ method not found in `Dwarf<EndianSlice<'_, LittleEndian>>`

Maybe those changes can be reverted, but I didn't try.

edit: going back to library/backtrace 4245978ca8169c40c088ff733825e4527f7b914c like 1.71 works.

gimli release PR is up. I'll do some testing and release gimli and addr2line tomorrow.

Upgrading beta std to addr2line v0.21.0 -> gimli v0.28.0 works! So I think we could do just that as a targeted fix for 1.72-beta, and a fuller update following rust-lang/backtrace-rs#557 on master for 1.73-nightly.

Add a regression test for rust-lang#113238

Rollup merge of rust-lang#114825 - cuviper:gimli-0.28, r=compiler-errors

#114955 / #114825 fixed this, so closing.

Navigation Menu

Repository navigation

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

21 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Activity

hameerabbasi commented on Jul 2, 2023

compiler-errors commented on Jul 2, 2023

compiler-errors commented on Jul 2, 2023

Mark-Simulacrum commented on Jul 2, 2023

cuviper commented on Jul 7, 2023

cuviper commented on Jul 7, 2023

Mark-Simulacrum commented on Jul 7, 2023

Noratrieb commented on Jul 7, 2023

cuviper commented on Jul 7, 2023

workingjubilee commented on Jul 7, 2023

21 remaining items

apiraino commented on Aug 1, 2023

wesleywiser commented on Aug 3, 2023

cuviper commented on Aug 12, 2023

philipc commented on Aug 12, 2023

cuviper commented on Aug 13, 2023

Mark-Simulacrum commented on Aug 18, 2023

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

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