Skip to content
New issue

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

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

Already on GitHub? # to your account

error: internal compiler error: adt::represent_type called on non-ADT type: &std ::io::IoError #20046

Closed
evmar opened this issue Dec 19, 2014 · 10 comments
Labels
I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️

Comments

@evmar
Copy link

evmar commented Dec 19, 2014

   Compiling sha1sum v0.0.1 (file:///home/evanm/projects/rust/sha1sum)
error: internal compiler error: adt::represent_type called on non-ADT type: &std::io::IoError
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: http://doc.rust-lang.org/complement-bugreport.html
note: run with `RUST_BACKTRACE=1` for a backtrace
task 'rustc' panicked at 'Box<Any>', /home/rustbuild/src/rust-buildbot/slave/nightly-linux/build/src/libsyntax/diagnostic.rs:188

stack backtrace:
   1:     0x7f5eb2c9af10 - rt::backtrace::imp::write::h28b8bbd9f503cf471Xx
   2:     0x7f5eb2c9e570 - failure::on_fail::hd0a2ddc03e0fa8a6opy
   3:     0x7f5eb28de6a0 - unwind::begin_unwind_inner::hedcb21b2885493daaNc
   4:     0x7f5eaff927e0 - unwind::begin_unwind::h14053085834319754591
   5:     0x7f5eaff93090 - diagnostic::Handler::bug::h88688dedb903e5ddeRF
   6:     0x7f5eb0ce1250 - session::Session::bug::hc1287fe1a705e6adSLu
   7:     0x7f5eb18261f0 - trans::adt::represent_type_uncached::he6675fb263092d5deMH
   8:     0x7f5eb1710530 - trans::adt::represent_type::hd46d360c5fae4210nIH
   9:     0x7f5eb17c2fc0 - trans::_match::compile_submatch_continue::hba348eef0dad30a0a2w
  10:     0x7f5eb17c0ab0 - trans::_match::compile_submatch::h908579cfdcf3da5fxWw
  11:     0x7f5eb17c2fc0 - trans::_match::compile_submatch_continue::hba348eef0dad30a0a2w
  12:     0x7f5eb17c0ab0 - trans::_match::compile_submatch::h908579cfdcf3da5fxWw
  13:     0x7f5eb17c7b10 - trans::_match::trans_match_inner::h4dfb82c4024d7437svx
  14:     0x7f5eb173b930 - trans::expr::trans_rvalue_dps_unadjusted::h1c34ba6d0fbc42abX8i
  15:     0x7f5eb16f7500 - trans::expr::trans_into::hea40bf13dbc784e8sFh
  16:     0x7f5eb16f6910 - trans::controlflow::trans_stmt_semi::h5ed64e36e117a6c8PYd
  17:     0x7f5eb16f7c60 - trans::controlflow::trans_block::h61d649e79c6d3e91IZd
  18:     0x7f5eb17408e0 - trans::expr::trans_rvalue_stmt_unadjusted::hdd4f67405c596af0e3i
  19:     0x7f5eb16f7500 - trans::expr::trans_into::hea40bf13dbc784e8sFh
  20:     0x7f5eb16f7c60 - trans::controlflow::trans_block::h61d649e79c6d3e91IZd
  21:     0x7f5eb17a6660 - trans::base::trans_closure::h4a257820d48920f5P8t
  22:     0x7f5eb16ec1d0 - trans::base::trans_fn::he64630405a744a1c6ju
  23:     0x7f5eb16e7850 - trans::base::trans_item::hedeca6906d42d5ef8Eu
  24:     0x7f5eb17ae5d0 - trans::base::trans_crate::h409f313f53dd00d1jBv
  25:     0x7f5eb30ff090 - driver::phase_4_translate_to_llvm::ha3e95ae8dd99774cXCa
  26:     0x7f5eb30d5ee0 - driver::compile_input::h3c93a433de329ec1rba
  27:     0x7f5eb328a020 - run_compiler::h6520470d7d92765aAYb
  28:     0x7f5eb3280c60 - thunk::F.Invoke<A,$u{20}R$GT$::invoke::h1449879172494822488
  29:     0x7f5eb2c732c0 - thunk::F.Invoke<A,$u{20}R$GT$::invoke::h14525951389403266713
  30:     0x7f5eb28dce10 - task::Task::spawn_thunk::closure.5804
  31:     0x7f5eb293b9b0 - rust_try_inner
  32:     0x7f5eb293b9a0 - rust_try
  33:     0x7f5eb28dcf20 - unwind::try::h870bc6c90527a031rCc
  34:     0x7f5eb28dccb0 - task::Task::run::h3063eac886af1b39tNb
  35:     0x7f5eb28dc420 - thunk::F.Invoke<A,$u{20}R$GT$::invoke::h6184366571468466973
  36:     0x7f5eb28ddd70 - thread::thread_start::h6cf2d96de299983bM4b
  37:     0x7f5ead3f30c0 - start_thread
  38:     0x7f5eb25a0ec9 - __clone
  39:                0x0 - <unknown>

Could not compile `sha1sum`.

To learn more, run the command again with --verbose.

Reduced code, with the line causing the ICE marked in a comment:

use std::io;

fn main() {
    let mut stdinx = io::stdio::stdin();
    let mut stdin = stdinx.lock();
    loop {
        match stdin.fill_buf() {
            Ok(_) => true,
            Err(ref e) if e.kind == io::EndOfFile => break,
            // *** I added the following line, seeing whether I could pattern
            // match instead of use a guard, and that produced the error.
            Err(io::IoError { kind: io::EndOfFile, ..}) => break,
            Err(err) => panic!(err)
        };
    }
}
@barosl
Copy link
Contributor

barosl commented Dec 20, 2014

Interesting. The ICE occurs only when both of the lines exist. If we comment out either line, it compiles well.

@ebadf
Copy link

ebadf commented Jan 4, 2015

looks like this still happens on a recent nightly (jan 1, 2015):

rust version:

rustc 0.13.0-nightly (39d740266 2015-01-01 15:51:08 +0000)
binary: rustc
commit-hash: 39d74026663597a8d4ad0ab04e6d117bf9fd6ad4
commit-date: 2015-01-01 15:51:08 +0000
host: i686-unknown-linux-gnu
release: 0.13.0-nightly

reduced repro code:

fn main() {
    match std::io::stdio::stdin().read_byte() {
        Ok(_) => (),
        Err(ref e) if e.kind == std::io::EndOfFile => (),
        Err(std::io::IoError { kind: EndOfFile, .. }) => (),
    }
}

still yields:

error: internal compiler error: adt::represent_type called on non-ADT type: &std::io::IoError
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: http://doc.rust-lang.org/complement-bugreport.html
note: run with `RUST_BACKTRACE=1` for a backtrace
thread 'rustc' panicked at 'Box<Any>', /home/rustbuild/src/rust-buildbot/slave/nightly-linux/build/src/libsyntax/diagnostic.rs:182

stack backtrace:
   1: 0xb73441f0 - sys::backtrace::write::h8c2ed683dda82704ist
   2: 0xb7367e70 - failure::on_fail::hebe4057108e7dc03xLz
   3: 0xb72d27d0 - rt::unwind::begin_unwind_inner::h420b24b59a4d3530ypz
   4: 0xb38c29b0 - rt::unwind::begin_unwind::h2881239313039487497
   5: 0xb38c31c0 - diagnostic::Handler::bug::he2275dda9c97b39dzWF
   6: 0xb617ba90 - session::Session::bug::hfd10fa89d9dc35a1zMp
   7: 0xb6b40ed0 - trans::adt::represent_type_uncached::h5e681bb076af3e1fzQH
   8: 0xb6a16b40 - trans::adt::represent_type::hb9fc6ac08f11ee404MH
   9: 0xb6aee400 - trans::_match::compile_submatch_continue::hd67afd18709f7004dax
  10: 0xb6aebde0 - trans::_match::compile_submatch::h7bf039279d178001J4w
  11: 0xb6aee400 - trans::_match::compile_submatch_continue::hd67afd18709f7004dax
  12: 0xb6aebde0 - trans::_match::compile_submatch::h7bf039279d178001J4w
  13: 0xb6af4e70 - trans::_match::trans_match_inner::h3e8caaa43b5a6eafoDx
  14: 0xb6a46770 - trans::expr::trans_rvalue_dps_unadjusted::hc875dbef972abc0a69i
  15: 0xb69f9890 - trans::expr::trans_into::hecc47d3a84ed0b18nIh
  16: 0xb69fa0d0 - trans::controlflow::trans_block::h0356beb9de683d99F6d
  17: 0xb6acdae0 - trans::base::trans_closure::h327ac755b34be94apfu
  18: 0xb69e8f20 - trans::base::trans_fn::heb29d5b7a30a15ebequ
  19: 0xb69e2a90 - trans::base::trans_item::ha87127dde51fdff3INu
  20: 0xb6ad6af0 - trans::base::trans_crate::ha55c3849272518cfNKv
  21: 0xb768c710 - driver::phase_4_translate_to_llvm::hed237fb0f43bd599IFa
  22: 0xb766b2f0 - driver::compile_input::h05aad328a73a6525wba
  23: 0xb77c5160 - thunk::F.Invoke<A, R>::invoke::h118516395371660300
  24: 0xb77c3f70 - rt::unwind::try::try_fn::h14176178842317427281
  25: 0xb73d7cd0 - rust_try_inner
  26: 0xb73d7ca0 - rust_try
  27: 0xb77c42b0 - thunk::F.Invoke<A, R>::invoke::h7075950477878468722
  28: 0xb7355520 - sys::thread::thread_start::hf2d9dfd6d613d3d2dlw
  29:        0x0 - <unknown>

dunno how martine arrived at this pattern match, but for me it was a case of being in transition from alex crichton's approach to handling EOF to steve fackler's, as proposed on [rust-dev] (https://mail.mozilla.org/pipermail/rust-dev/2014-February/008513.html). which in and of itself might be an indication that perhaps the subject of recommended EOF handling strategy for std::io::Reader et al. ought to be broached somewhere in the docs (the guide? std lib ref?)...

@kmcallister kmcallister added the I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ label Jan 9, 2015
@tamird
Copy link
Contributor

tamird commented Apr 21, 2015

This doesn't compile and the proposed pattern match is much deeper now due to changes to io::Error. @ebadf could you try to refresh the test case?

@eefriedman
Copy link
Contributor

Updated testcase; still crashes on nightly.

#[derive(PartialEq)]
enum IoErrorKind { BrokenPipe, XXX }
struct IoError {
    pub kind: IoErrorKind,
    pub detail: Option<String>
}
fn main() {
    let e: Result<u8, _> = Err(IoError{ kind: IoErrorKind::XXX, detail: None });
    match e {
        Ok(_) => true,
        Err(ref e) if e.kind == IoErrorKind::BrokenPipe => return,
        Err(IoError { kind: IoErrorKind::BrokenPipe, ..}) => return,
        Err(err) => panic!(err)
    };
}

eefriedman added a commit to eefriedman/rust that referenced this issue Jul 15, 2015
The old code was not well structured, difficult to understand,
and buggy.

The new implementation is completely naive, so there may be a slight
runtime performance loss. That said, adding optimizations on top of
a clear and correct implementation seems easier than trying to
fix the old mess.

Fixes issue rust-lang#19064.
Fixes issue rust-lang#26989.
Fixes issue rust-lang#26251.
Fixes issue rust-lang#18060.
Fixes issue rust-lang#24875.
Fixes issue rust-lang#23311.
Fixes issue rust-lang#20046.
bltavares pushed a commit to bltavares/glacier that referenced this issue Oct 24, 2015
@huonw
Copy link
Member

huonw commented Oct 29, 2015

Slightly more reduced:

// FAILS
enum X {
    Y(())
}
fn main() {
    let x = &X::Y(());
    match x {
        &X::Y(ref _x) if true => {},
        &X::Y(()) => {},
    }
}

Notably, the ref arm appears to have to be conditional in some way, e.g.: a tuple with other patterns:

// FAILS
enum X {
    Y(())
}
fn main() {
    let x = X::Y(());
    match (true, &x) {
        (true, &X::Y(ref _x))  => {},
        (_, &X::Y(())) => {},
    }
}

vs. swapping which arm has the guard:

// ok
enum X {
    Y(())
}
fn main() {
    let x = X::Y(());
    match &x {
        &X::Y(()) if true => {},
        &X::Y(ref _x)  => {},
    }
}

And the order matters, e.g.:

// FAILS
enum X {
    Y(())
}
fn main() {
    let x = X::Y(());
    match &x {
        &X::Y(ref _x) if true => {},
        &X::Y(()) if true => {},
        _ => {}
    }
}
// ok
enum X {
    Y(())
}
fn main() {
    let x = X::Y(());
    match &x {
        &X::Y(()) if true => {},
        &X::Y(ref _x) if true => {},
        _ => {}
    }
}

I.e. a workaround (if it is semantically correct for the program) is to move the ref version later.

@SimonSapin
Copy link
Contributor

I’m getting a similar error on servo/rust-layers#218 / servo/rust-layers@39a38c5

error: internal compiler error: adt::represent_type called on non-ADT type: [type error]

Interestingly, it happens with the current Nightly: rustc 1.6.0-nightly (52d95e6 2015-11-30) but not with the version used in Servo: rustc 1.6.0-nightly (d5fde83 2015-11-12)

@arielb1
Copy link
Contributor

arielb1 commented Nov 30, 2015

@SimonSapin

sounds like a different bug. Could you please report it separately?

@SimonSapin
Copy link
Contributor

I was told this one is likely fixed by #30116. Indeed, removing (..) in a pattern for a unit enum variant worked around it.

@nagisa
Copy link
Member

nagisa commented Jan 1, 2016

I’ve hit this with something like following:

                    (_, &mir::CallKind::ConvergingCleanup { targets: (target, _), .. }) |
                    (_, &mir::CallKind::Converging { target, .. }) => {

which resulted in

adt::represent_type called on non-ADT type: &'static (rustc::mir::repr::BasicBlock, rustc::mir::repr::BasicBlock)

@steveklabnik
Copy link
Member

@eefriendman's test case #20046 (comment)

now compiles as of

rustc 1.12.0-nightly (a005b6785 2016-08-02)

as does @huonw's #20046 (comment)

As such, I'm going to give this one a close. Let me know if this can still be reproduced!

steveklabnik added a commit to rust-lang/glacier that referenced this issue Aug 4, 2016
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
Projects
None yet
Development

No branches or pull requests