SIGSEGV matching a struct-like enum in a macro

[sfackler]

enum Foo {
    A { a: int },
    B { b: int, bb: int },
}

macro_rules! thingy2(
    () => (
        match B { b: 10, bb: 10 } {
            A { a } => println!("{}", a),
            B { b, bb } => println!("{} {}", b, bb),
        }
    )
)

fn main() {
    thingy2!()
}

~ ❯ rustc -Z debug-info test.rs
~ ❯ gdb test
GNU gdb 6.3.50-20050815 (Apple version gdb-1824) (Wed Feb  6 22:51:23 UTC 2013)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared libraries .. done

(gdb) r
Starting program: /Users/sfackler/test
Reading symbols for shared libraries ..+................................................................. done

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000001
[Switching to process 59143 thread 0x40b]
0x000000010000171f in main () at <std-macros>:291
291 <std-macros>: No such file or directory.
    in <std-macros>

If I change Foo to

enum Foo {
    A(int),
    B(int, int)
}

The program works as expected. Manually expanding the macro invocation also causes the program to work correctly.

[sfackler]

This regressed in the last day or two.

[sfackler]

#9026 caused this. The program above runs fine if 124eb21 is reverted.

[jbclements]

goodness... there's something really freaky going on here. I've found a program near this one that actually behaves nondeterministically:

enum Foo {
    A { a: int, aa: int },
    B { b: int, bb: int },
}

macro_rules! thingy2(
    () => (
        match B { b: 10, bb: 10 } {
            A { a , aa} => 13,
            B { b , bb } => 14
        }
    )
)

fn main() {
    println!("{}",thingy2!());
}

It seems to seg fault about 1/5 of the time:

pcp068341pcs:/tmp clements> ./foo
14
pcp068341pcs:/tmp clements> ./foo
14
pcp068341pcs:/tmp clements> ./foo
14
pcp068341pcs:/tmp clements> ./foo
zsh: segmentation fault  ./foo
pcp068341pcs:/tmp clements> ./foo
14
pcp068341pcs:/tmp clements> ./foo
14
pcp068341pcs:/tmp clements> ./foo
14
pcp068341pcs:/tmp clements> ./foo
14
pcp068341pcs:/tmp clements> ./foo
14
pcp068341pcs:/tmp clements> ./foo
14
pcp068341pcs:/tmp clements> ./foo
14
pcp068341pcs:/tmp clements> ./foo
14
pcp068341pcs:/tmp clements> ./foo
14
pcp068341pcs:/tmp clements> ./foo
14
pcp068341pcs:/tmp clements> ./foo
14
pcp068341pcs:/tmp clements> ./foo
zsh: segmentation fault  ./foo
pcp068341pcs:/tmp clements> 

[jbclements]

BTW, what platform did you observe this on?

[sfackler]

Both 64 bit Linux and OSX.

[jbclements]

Okay, narrowing down; it looks like the post-patch version is omitting storage into local vars in the LLVM. I'm guessing this is because of an illegal ident comparison. I'd stick the LLVM diff in here but... I don't think it would be helpful to anyone but me.

[jbclements]

okay, I think I've got the fix for this one. Now to add a test case and run make check....

[jbclements]

apparently fixed by #9090 .