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

internal compiler error preventing servo from compiling on OS X 10.8 #6117

Closed
bdaehlie opened this issue Apr 29, 2013 · 5 comments
Closed

internal compiler error preventing servo from compiling on OS X 10.8 #6117

bdaehlie opened this issue Apr 29, 2013 · 5 comments
Labels
I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️

Comments

@bdaehlie
Copy link

Compiling servo fails on OS X 10.8 due to an internal compiler error.

rust: task failed at 'index out of bounds: the len is 0 but the index is 0', /Users/josh/src/mozilla/rust/src/librustc/middle/trans/_match.rs:1283
error: internal compiler error: unexpected failure

This happens with current rust trunk, usually while compiling "servo-gfx".

@sethfowler
Copy link

Here's a log with RUST_LOG=rustc::middle::trans: https://gist.github.com/sfowler/5485802

@ILyoan
Copy link
Contributor

ILyoan commented Apr 30, 2013

This also appears on linux

@jld
Copy link
Contributor

jld commented Apr 30, 2013

rust: ~"Representing: core::result::Result<@?,()>"

I wonder if I did something subtly wrong with pattern-matching on nullable-pointer enums (d0451ee).

@ghost ghost assigned jld Apr 30, 2013
@jld
Copy link
Contributor

jld commented Apr 30, 2013

In answer to my own question: Yes, I did.

@jld
Copy link
Contributor

jld commented Apr 30, 2013

This test case is smaller than servo:

pub fn main() {
        match Left(@17) {
                Right(()) => {}
                _ => {}
        }
}

jld added a commit to jld/rust that referenced this issue Apr 30, 2013
Cases like `Either<@int,()>` have a null case with at most one value but
a nonzero number of fields; if we misreport this, then bad things can
happen inside of, for example, pattern matching.

Closes rust-lang#6117.
bors added a commit that referenced this issue Apr 30, 2013
Cases like `Either<@int,()>` have a null case with at most one value but
a nonzero number of fields; if we misreport this, then bad things can
happen inside of, for example, pattern matching.

Closes #6117.
@metajack metajack closed this as completed May 1, 2013
flip1995 pushed a commit to flip1995/rust that referenced this issue Oct 9, 2020
Downgrade string_lit_as_bytes to nursery

Between rust-lang#1402 (regarding `to_owned`) and rust-lang#4494 (regarding `impl Read`), as well as other confusion I've seen hit in my work codebase involving string_lit_as_bytes (`"...".as_bytes().into()`), I don't think this lint is at a quality to be enabled by default.

I would consider re-enabling this lint after it is updated to understand when the surrounding type information is sufficient to unsize `b"..."` to &\[u8\] without causing a type error.

As currently implemented, this lint is pushing people to write `&b"_"[..]` which is not an improvement over `"_".as_bytes()` as far as I am concerned.

---

changelog: Remove string_lit_as_bytes from default set of enabled lints
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
Projects
None yet
Development

No branches or pull requests

5 participants