Skip to content

tuples with unsized tails cause an error when compiled #33241

Description

@arielb1

STR

use std::fmt;

// CoerceUnsized is not implemented for tuples. You can still create
// an unsized tuple by transmuting a trait object.
fn any<T>() -> T { unreachable!() }

fn main() {
    let t: &(u8, fmt::Debug) = any();
    println!("{:?}", &t.1);
}

Actual Results

Before #32939, this caused an LLVM error

Stored value type does not match pointer operand type!
  store i8 %17, void (i8*)*** %18
 void (i8*)**LLVM ERROR: Broken function found, compilation aborted!

Afterwards, this causes an ICE (the rustc size is the correct one):

error: internal compiler error: ../src/librustc_trans/type_of.rs:142: size differs (rustc: 1, llvm: 24) for type `(u8, std::fmt::Debug + 'static)` / Univariant {
    variant: Struct {
        align: Align {
            raw: 48
        },
        packed: false,
        sized: false,
        offset_after_field: [
            Size {
                raw: 1
            },
            Size {
                raw: 1
            }
        ]
    },
    non_zero: false
}

Activity

  1. added
    I-ICEIssue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
    T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
    on Apr 27, 2016
  2. Mark-Simulacrum commented on May 3, 2017

    @Mark-Simulacrum
    Member

    I am now getting a segfault in LLVM, but I'm uncertain whether that's actually the case, or just a local build problem.

    #0  0x00007f433e6d9910 in LLVMTypeOf () from /rust/build/x86_64-unknown-linux-gnu/stage1/bin/../lib/../lib/librustc_llvm-97d4717776475ef1.so
    #1  0x00007f4343a386e9 in rustc_trans::base::from_immediate (bcx=0x7f4339d27ea0, val=0x0) at /rust/src/librustc_trans/base.rs:464
        at /rust/src/librustc_trans/mir/operand.rs:340
        at /rust/src/librustc_trans/mir/rvalue.rs:161
        at /rust/src/librustc_trans/mir/statement.rs:35
    #5  rustc_trans::mir::block::{{impl}}::trans_block (self=<optimized out>, bb=..., funclets=<optimized out>) at /rust/src/librustc_trans/mir/block.rs:109
        at /rust/src/librustc_trans/mir/mod.rs:330
    #7  0x00007f4343a38ff5 in rustc_trans::base::trans_instance (ccx=0x7f4339d2cf38, instance=...) at /rust/src/librustc_trans/base.rs:606
    #8  0x00007f4343ade88d in rustc_trans::trans_item::{{impl}}::define (self=0x7f4339d2c880, ccx=<optimized out>) at /rust/src/librustc_trans/trans_item.rs:104
    #9  0x00007f4343a3f5b0 in rustc_trans::base::trans_crate::module_translation (scx=..., args=...) at /rust/src/librustc_trans/base.rs:1185
        task=0x7f4343a3ee10 <rustc_trans::base::trans_crate::module_translation>) at /rust/src/librustc/dep_graph/graph.rs:111
    #11 0x00007f4343a29a76 in rustc_trans::base::trans_crate::{{closure}} (cgu=...) at /rust/src/librustc_trans/base.rs:1119
    #12 core::ops::impls::{{impl}}::call_once<(rustc_trans::partitioning::CodegenUnit),closure> (self=0x7f4339d2d540, args=...) at /rust/src/libcore/ops.rs:2674
        at /rust/src/libcore/option.rs:392
        at /rust/src/libcore/iter/mod.rs:1011
        self=<optimized out>, iterator=...) at /rust/src/libcollections/vec.rs:1761
        iterator=...) at /rust/src/libcollections/vec.rs:1744
    #17 0x00007f4343a3bc9e in collections::vec::{{impl}}::from_iter<rustc_trans::ModuleTranslation,core::iter::Map<collections::vec::IntoIter<rustc_trans::partitioning::CodegenUnit>, closure>> (iter=...) at /rust/src/libcollections/vec.rs:1631
    #18 core::iter::iterator::Iterator::collect<core::iter::Map<collections::vec::IntoIter<rustc_trans::partitioning::CodegenUnit>, closure>,collections::vec::Vec<rustc_trans::ModuleTranslation>> (self=...) at /rust/src/libcore/iter/iterator.rs:1222
    #19 rustc_trans::base::trans_crate (tcx=..., analysis=..., incremental_hashes_map=<optimized out>) at /rust/src/librustc_trans/base.rs:1114
    #20 0x00007f434481e106 in rustc_driver::driver::phase_4_translate_to_llvm::{{closure}} () at /rust/src/librustc_driver/driver.rs:1080
    #21 rustc::util::common::time<rustc_trans::CrateTranslation,closure> (do_it=<optimized out>, what=..., f=...) at /rust/src/librustc/util/common.rs:57
        at /rust/src/librustc_driver/driver.rs:1078
        at /rust/src/librustc_driver/driver.rs:206
    #24 0x00007f434485ca21 in rustc_driver::driver::phase_3_run_analysis_passes::{{closure}}<closure,core::result::Result<(rustc::session::config::OutputFilenames, rustc_trans::CrateTranslation), usize>> (tcx=...) at /rust/src/librustc_driver/driver.rs:1024
    #25 0x00007f434480d6ef in rustc::ty::context::tls::enter::{{closure}}<closure,core::result::Result<core::result::Result<(rustc::session::config::OutputFilenames, rustc_trans::CrateTranslation), usize>, usize>> (tls=0x7f4339d40570) at /rust/src/librustc/ty/context.rs:921
        f=...) at /rust/src/libstd/thread/local.rs:253
        gcx=<optimized out>, interners=<optimized out>, f=...) at /rust/src/librustc/ty/context.rs:918
    
  3. eddyb commented on May 3, 2017

    @eddyb
    Contributor

    Looks like from_immediate called on a NULL pointer? Probably some missing check that something is indeed unsized, with actual metadata to go alongside it.

  4. Mark-Simulacrum commented on Jun 22, 2017

    @Mark-Simulacrum
    Member

    Appears to be fixed today. E-needstest.

  5. added
    E-needs-testCall for participation: An issue has been fixed and does not reproduce, but no test has been added.
    on Jun 22, 2017
  6. added a commit that references this issue on Oct 4, 2017
    7428806
  7. estebank commented on Oct 4, 2017

    @estebank
    Contributor

    It seems that a better diagnostic output is needed:

    error: compilation successful
      --> src/main.rs:11:1
       |
    11 | / fn main() { //~ ERROR compilation successful
    12 | |     let t: &(u8, fmt::Debug) = any();
    13 | |     println!("{:?}", &t.1);
    14 | | }
       | |_^
    
  8. eddyb commented on Oct 4, 2017

    @eddyb
    Contributor

    @estebank Why? I believe it's implemented as a feature now (maybe it should be run-pass?).

  9. estebank commented on Oct 4, 2017

    @estebank
    Contributor

    @eddyb it's unrelated to this issue, but rather to #45020's solution, error: compilation successful merits at least a clarifying label pointing at the #[rustc_error], as otherwise the compiler output makes you look at the following line exclusively, which isn't the cause for the error. I know it definitely confused me :)

    Back to this issue, yes, the test in #45020 should be run-pass.

  10. added a commit that references this issue on Oct 8, 2017
    ade0b01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    C-bugCategory: This is a bug.E-needs-testCall for participation: An issue has been fixed and does not reproduce, but no test has been added.I-ICEIssue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions