Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

assertion failed: (left == right) && (right == left) (left: 1, right: 0) #8516

Closed
carl-eastlund opened this issue Aug 14, 2013 · 8 comments
Closed
Labels
E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️

Comments

@carl-eastlund
Copy link

Here's the program:

enum Either {One(()), Other{left:~str,right:~str}}
static one : Either = One(());
fn main () {}

Here's the error message:

task <unnamed> failed at 'assertion failed: `(left == right) && (right == left)` (left: `1`, right: `0`)', /Users/cce/git/rust/src/librustc/middle/trans/adt.rs:521
error: internal compiler error: unexpected failure
note: the compiler hit an unexpected failure path. this is a bug
note: try running with RUST_LOG=rustc=1,::rt::backtrace to get further details and report the results to github.com/mozilla/rust/issues
task <unnamed> failed at 'explicit failure', /Users/cce/git/rust/src/librustc/rustc.rs:371
@lilyball
Copy link
Contributor

I tried looking into this a bit. The failed assertion is in middle::trans::adt::trans_const(), when it checks for NullablePointer. After determining that this is the null case, it asserts that vals.len() is 0, and that's the assertion that fails.

I'm not particularly familiar with this code (or really, any of the compiler yet), but the null case in this enum is of course One(()). I imagine the one value that's present is the (). The docstr for NullablePointer says that the null case "is inhabited by at most one value". This seems to be at odds with the assertion that checks vals.len() == 0 (assuming that vals here is what the docstr is referring to).

@jld
Copy link
Contributor

jld commented Aug 16, 2013

Indeed, that assertion is wrong and should be deleted. A variant with size-0 contents is eligible to be a null pointer, but since size-0 types like () exist, it can have a nonzero number of fields.

The test nullable-pointer-iotareduction.rs would have caught that — the type used there is enum E<T> { Thing(int, T), Nothing((), ((), ()), [i8, ..0]) }, for exactly this reason — but somehow I forgot to test statics.

@emberian
Copy link
Member

Updated code, new assertion:

#[feature(struct_variant)];             

enum Either {                           
    One(()),                            
    Other { left:~str, right:~str}      
}                                       

static one : Either = One(());          
fn main () {}                           
foo.rs:3:1: 6:2 warning: code is never used: `Either`, #[warn(dead_code)] on by default                                        
foo.rs:3 enum Either {                                                                                                         
foo.rs:4     One(()),                                                                                                          
foo.rs:5     Other { left:~str, right:~str}                                                                                    
foo.rs:6 }                                                                                                                     
foo.rs:8:1: 8:31 warning: code is never used: `one`, #[warn(dead_code)] on by default                                          
foo.rs:8 static one : Either = One(());                                                                                        
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~                                                                                        
error: internal compiler error: unexpected failure                                                                             
This message reflects a bug in the Rust compiler.                                                                              
We would appreciate a bug report: http://static.rust-lang.org/doc/master/complement-bugreport.html                             
note: the compiler hit an unexpected failure path. this is a bug                                                               
Ok(task 'rustc' failed at 'assertion failed: !is_undef(wrapped)', /build/rust-git/src/rust/src/librustc/middle/trans/adt.rs:796
)                                                                                                                              

@eddyb
Copy link
Member

eddyb commented Mar 2, 2014

This doesn't need #[feature(struct_variant)];, the source of the problem is One(()).
@carl-eastlund, could you update the issue description?

@carl-eastlund
Copy link
Author

I haven't looked at Rust or this issue in several months; if there's
something in the issue that only I can update, you'll have to spell out
what I need to change it to. A lot of these details are paged out of my
mind right now.

Carl Eastlund

On Sun, Mar 2, 2014 at 5:19 AM, Eduard Burtescu notifications@git.luolix.topwrote:

This doesn't need #[feature(struct_variant)];, the source of the problem
is One(()).
@carl-eastlund https://github.com/carl-eastlund, could you update the
issue description?


Reply to this email directly or view it on GitHubhttps://github.com//issues/8516#issuecomment-36450694
.

@emberian
Copy link
Member

emberian commented Mar 2, 2014

@eddyb the issue description doesn't really need updating, especially since there's no specifics still.

@jld
Copy link
Contributor

jld commented Mar 5, 2014

I'm sure I commented on this somewhere at some point since I wrote that last comment — I was assuming that an undef could be wrapped in a struct to make it not-undef (because undef is used for alignment padding, because we have to add our own for constants in some cases), but that doesn't actually work. So the !is_undef assertion actually does indicate that stuff would break otherwise. The code that fills in undef for the unused fields of non-nullary null pointer variants should just use C_null, I think.

@jld
Copy link
Contributor

jld commented Mar 5, 2014

…and that's #8506. I'll close this, because the failure this was initially opened for was fixed in 5487f15 / #11441, but I apparently forgot the “Closes” annotation on the commit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
Projects
None yet
Development

No branches or pull requests

5 participants