LLVM assertion failure with unreachable vector add

[catamorphism]

fn fail_then_concat() {
    let x = ~[], y = ~[3];
    fail;
    x += y;
    ~"good" + ~"bye";
}

fn main() {}

rust: task failed at 'Assertion llvm::LLVMGetPointerAddressSpace(val_ty(val)) as uint == 1u failed', /Users/TimChevalier/rust/src/rustc/middle/trans/base.rs:2712

[catamorphism]

This seems to be a bug in liveness: because of the fail that dominates the vector add, the x += y doesn't get reported as illegal (since x is immutable). I don't know exactly why the assertion failure, but the code should get rejected beforehand anyway.

I don't really understand the liveness code, though; @nikomatsakis , maybe you can help me with this tomorrow when I'm back in the office.

[nikomatsakis]

this is sort of... by design. but perhaps the design is wrong. that is, liveness sees that in any plausible execution of that fn, x can never be modified, so it is happy.

[catamorphism]

I'm going to consider this to be a WONTFIX; I find the behavior a little weird, but I guess it can't be harmful.

[nikomatsakis]

I disagree with closing this bug, though I agree it is not high priority.

[nikomatsakis]

Do we even know what causes this failure in trans? My guess would be some sort of table that indicates whether a value is mutated. There used to be such a table that was used to decide whether a variable would be treated as "immediate" or stored on the stack. However, I thought that sully removed the use of this table a while and just stored all variables on the stack, as this is apparently what clang does anyway and makes things simple: so perhaps there is another table? Or I am wrong about this table having been removed? In either case, the fix is probably to modify the criteria used for listing things in this table, it's no doubt some sort of over-eager and possibly premature optimization.

[catamorphism]

The trans failure appears to be magically fixed -- test case pushed in 885f0a2