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

ref pattern nested inside let LHS causes LLVM assertion failure #3874

Closed
nejucomo opened this issue Oct 27, 2012 · 7 comments
Closed

ref pattern nested inside let LHS causes LLVM assertion failure #3874

nejucomo opened this issue Oct 27, 2012 · 7 comments
Assignees
Labels
A-codegen Area: Code generation I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️

Comments

@nejucomo
Copy link

The following code (which may not be correct rust) causes an llvm abort on my build.

$ cat ./experiment.rs

enum PureCounter { PureCounter(uint) }

impl PureCounter : iter::BaseIter<uint> {
    pure fn each(blk: fn(v: &uint) -> bool) {
        let PureCounter(ref x) = self;
        match blk(x) {
          true => PureCounter( (*x) + 1 ).each(blk),
          false => ()
        }
    }

    pure fn size_hint() -> Option<uint> { None }
}

fn main() {
    do PureCounter(0).each |nbox| {
        io::println( (*nbox).to_str() );
        (*nbox) < 5
    }
}

$ rustc ./experiment.rs
rustc: /home/n/sandbox/3p/rust/src/llvm/lib/VMCore/Instructions.cpp:1062: void llvm::StoreInst::AssertOK(): Assertion `getOperand(0)->getType() == cast<PointerType>(getOperand(1)->getType())->getElementType() && "Ptr must be a pointer to Val type!"' failed.
Aborted

$ rustc --version
rustc 0.5 (07edf90 2012-10-13 05:57:13 -0700)
host: x86_64-unknown-linux-gnu
@catamorphism
Copy link
Contributor

Minimized version:

enum PureCounter { PureCounter(uint) }

pure fn each(self: PureCounter, blk: fn(v: &uint)) {
    let PureCounter(ref x) = self;
    blk(x);
}

fn main() {}

I suspect ref patterns in fields in let patterns don't work right. This will be addressed when I finish fixing #3235.

Changing the title to something more informative.

catamorphism added a commit that referenced this issue Nov 1, 2012
@catamorphism
Copy link
Contributor

Bumping to 0.6 since #3235 is not done.

@martica
Copy link
Contributor

martica commented Jan 24, 2013

I'm not sure if this is the same bug, but I'm getting the same assert with this code (I've minimized it as much as I can):

macro_rules! a_macro {
    ($zero:expr) => {
        pub fn foo() -> int {
            let x:int = $zero;
            x + $zero.add(&1)
        }
    }
}

a_macro!(0i)

fn main() { }

The code works when it has been manually expanded, so it appears to related to the use of a macro.

@catamorphism
Copy link
Contributor

Reproduced as of 373504, but not critical for 0.6; de-milestoning

@catamorphism
Copy link
Contributor

Nominating for milestone 5 (production-ready)

@ghost ghost assigned nikomatsakis May 28, 2013
@nikomatsakis
Copy link
Contributor

I dusted off my branch recently and am looking at this again.

@alexcrichton
Copy link
Member

Closed by #7262

huonw referenced this issue in flaper87/rust Jul 7, 2014
RalfJung pushed a commit to RalfJung/rust that referenced this issue Sep 17, 2024
a bit of refactoring in "sync"

- Use `Box<dyn Any>` to keep the "extra data" local to the module implementing the primitive
- Pass around places, not pointers

Cc `@Mandragorian` -- sorry I couldn't resist and did the `Any` thing ;)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-codegen Area: Code generation I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
Projects
None yet
Development

No branches or pull requests

5 participants