Unexpected tail in unsized_info_ty: usize for ty=process::Core<isize, isize, isize> #32377
Comments
|
This is the smallest test case I could find : use std::mem;
use std::marker::PhantomData;
trait Foo {
type Error;
}
struct Bar<U: Foo> {
stream: PhantomData<U::Error>,
}
fn foo<U: Foo>() -> Bar<U> {
unsafe { mem::transmute([0u32; 4]) }
}I am puzzled by the fact that isize does not appear once in the snippet. Potentially related, if I change the transmute to eg |
alexcrichton
added
I-nominated
regression-from-stable-to-nightly
|
Going down the rabbit hole, Later, From my limited understanding of Where the latest nightly differs, is at type_of.rs#L59. Instead of using a using a pointer for the second field, it now calls This is going a bit too deep into the compiler internals for me, but I think 1d7c9bd only made this existing problem visible. I'm not sure how substituting an isize can really work, especially when dealing with associated types. Here's the relevant debug output from |
|
Here is a related ICE on stable http://is.gd/OozIh7 Instead, it would have to substitute it first by a type whose associated type is Sized, then by one which isn't, recursively and exponentially for each type parameter / associated type. However, this is probably hinting at the fact that substitution by dummy types isn't the right way to do it, no that I have any idea what that would be. |
|
Guess this is a good time to move representation higher up to not depend on LLVM. |
|
Discussed in @rust-lang/compiler meeting. This is tricky to prioritize. @eddyb is right that the best solution is to stop relying on LLVM to compute sizes for us. Moreover, the examples given -- or at least the first one -- are in error (even though they ought not to ICE). It's very odd that the stable compiler accepts it. @plietar, do you have any inkling of the code in the original crate that is now ICEing? |
|
I've run into this ICE when building the eventual crate. This is causing my librespot build to fail on nightly as opposed to nightly 2016-03-17 or earlier |
|
@plietar Looking at that code, it is a You can just use |
|
Just ran into this, FWIW, in some old hacky code that turned out to be unnecessary. (I wanted to write |
These were exposing a compiler crash on the latest nightly. See rust-lang/rust#32377.
|
This regression is also present in |
|
@alexcrichton Hitting this means the code was wrong to begin with (and will receive a |
|
Ah yeah sorry to clarify I just ran a crate report against stable and those two crates just showed up with this same assertion (sorry I don't know much about the underlying issue here) |
|
@eddyb For what definition of wrong? Are you saying that |
|
@comex Actually, I've taken a closer look and neither I guess I'll try to track it down before working on the generalized solution. |
|
Turns out that |
|
triage: P-high |
These were exposing a compiler crash on the latest nightly. See rust-lang/rust#32377.
|
@eddyb are you saying that the value is considered unsized because |
Compute LLVM-agnostic type layouts in rustc. Layout for monomorphic types, and some polymorphic ones (e.g. `&T` where `T: Sized`), can now be computed by rustc without involving LLVM in the actual process. This gives rustc the ability to evaluate `size_of` or `align_of`, as well as obtain field offsets. MIR-based CTFE will eventually make use of these layouts, as will MIR trans, shortly. Layout computation also comes with a `[breaking-change]`, or two: * `"data-layout"` is now mandatory in custom target specifications, reverting the decision from #27076. This string is needed because it describes endianness, pointer size and alignments for various types. We have the first two and we could allow tweaking alignments in target specifications. Or we could also extract the data layout from LLVM and feed it back into rustc. However, that can vary with the LLVM version, which is fragile and undermines stability. For built-in targets, I've added a check that the hardcoded data-layout matches LLVM defaults. * `transmute` calls are checked in a stricter fashion, which fixes #32377 To expand on `transmute`, there are only 2 allowed patterns: between types with statically known sizes and between pointers with the same potentially-unsized "tail" (which determines the type of unsized metadata they use, if any). If you're affected, my suggestions are: * try to use casts (and raw pointer deref) instead of transmutes * *really* try to avoid `transmute` where possible * if you have a structure, try working on individual fields and unpack/repack the structure instead of transmuting it whole, e.g. `transmute::<RefCell<Box<T>>, RefCell<*mut T>>(x)` doesn't work, but `RefCell::new(Box::into_raw(x.into_inner()))` does (and `Box::into_raw` is just a `transmute`)
Hi,
compiling the eventual crate with the latest rust nightly (2016-03-20) gives me the following ICE. The previous nightly (2016-03-17) worked fine.
EDIT: I had copied the rust nightly versions incorrectly
The text was updated successfully, but these errors were encountered: