univariant: field #2 comes after unsized field #123134
Comments
lylythechosenone
added
C-bug
rustbot
added
the
needs-triage
compiler-errors
added
the
E-needs-mcve
|
@compiler-errors I'm not really sure how to minimize it. Currently, I have no idea which struct is causing the error, nor why. I have tried using P.S. the scope of the changes isn't too huge, and I'm 100% sure that the issue relates to the new |
|
|
Alright I may have actually just found it. It seems like it's in this struct: pub struct OpenDevice<A: Api>
where
A::Device: Sized,
A::Queue: Sized,
{
pub device: A::Device,
pub queue: A::Queue,
} |
|
Here is a self-contained reproducer, can probably be minimized further: playground link trait Api: Sized {
type Device: ?Sized;
}
struct OpenDevice<A: Api>
where
A::Device: Sized,
{
device: A::Device,
queue: (),
}
trait Adapter {
type A: Api;
fn open() -> OpenDevice<Self::A>
where
<Self::A as Api>::Device: Sized;
}
struct ApiS;
impl Api for ApiS {
type Device = [u8];
}
impl<T> Adapter for T {
type A = ApiS;
fn open() -> OpenDevice<Self::A>
where
<Self::A as Api>::Device: Sized,
{
unreachable!()
}
} |
jieyouxu
added
A-layout
|
@lukas-code thank you very much. I was gone else I would've done that myself 😅. |
|
Regression in nightly-2023-08-30 |
skip known panics lint for impossible items fixes rust-lang#123134 For items with impossible predicates like `[u8]: Sized` it's possible to have locals that are "Sized", but cannot be const-propped in any meaningful way. To avoid this issue, we can just skip the known panics lint for items that have impossible predicates.
matthiaskrgr
added
the
S-bug-has-test
layout computation: gracefully handle unsized types in unexpected locations This PR reworks the layout computation to eagerly return an error when encountering an unsized field where a sized field was expected, rather than delaying a bug and attempting to recover a layout. This is required, because with trivially false where clauses like `[T]: Sized`, any field can possible be an unsized type, without causing a compile error. Since this PR removes the `delayed_bug` method from the `LayoutCalculator` trait, it essentially becomes the same as the `HasDataLayout` trait, so I've also refactored the `LayoutCalculator` to be a simple wrapper struct around a type that implements `HasDataLayout`. The majority of the diff is whitespace changes, so viewing with whitespace ignored is advised. implements rust-lang/rust#123169 (comment) r? `@compiler-errors` or compiler fixes rust-lang/rust#123134 fixes rust-lang/rust#124182 fixes rust-lang/rust#126939 fixes rust-lang/rust#127737
layout computation: gracefully handle unsized types in unexpected locations This PR reworks the layout computation to eagerly return an error when encountering an unsized field where a sized field was expected, rather than delaying a bug and attempting to recover a layout. This is required, because with trivially false where clauses like `[T]: Sized`, any field can possible be an unsized type, without causing a compile error. Since this PR removes the `delayed_bug` method from the `LayoutCalculator` trait, it essentially becomes the same as the `HasDataLayout` trait, so I've also refactored the `LayoutCalculator` to be a simple wrapper struct around a type that implements `HasDataLayout`. The majority of the diff is whitespace changes, so viewing with whitespace ignored is advised. implements rust-lang/rust#123169 (comment) r? `@compiler-errors` or compiler fixes rust-lang/rust#123134 fixes rust-lang/rust#124182 fixes rust-lang/rust#126939 fixes rust-lang/rust#127737
Code
I'm not sure what exactly causes the ICE, but it happened in commit 0bb2479 on my fork of wgpu (lylythechosenone/wgpu).
Meta
rustc --version --verbose:Error output
Backtrace
The text was updated successfully, but these errors were encountered: