ICE; two sources of truth on how stuff is returned do not agree with each other

[nagisa]

Consider this code:

#![feature(no_core, lang_items,start)]
#![no_std]
#![no_core]
#[lang="sized"] trait Sized {}
#[lang="copy"] trait Copy {}

#[repr(u64)]
enum A {
    A = 0u64,
    B = !0u64,
}

fn cmp() -> A {
    A::B
}

#[start]
fn main(b:isize, a: *const *const u8)->isize { 0 }

if compiled targetting i686 target, this ICEs with

error: internal compiler error: ../src/librustc_trans/mir/operand.rs:82: impossible case reached

---

This is because ABI code claims that this u64 enum has to be returned via value (i.e. ret i64 %smth):

FnType { args: [], ret: ArgType { kind: Direct, original_ty: i64, ty: i64, signedness: Some(false), cast: None, ... }

Whereas MIR only has OperandRef(Ref(...)) because the common::is_immediate_type returns false for this enum. Calling immediate() on this OperandRef then causes this ICE.

This is a regression from the old->MIR trans move.

[nikomatsakis]

cc @eddyb, who has done a lot of poking at this infrastructure.

@nagisa, did you have a feeling for which is correct?

[eddyb]

Ugh, .immediate() is so risky. IMO the correct thing to do is to force a load if it's by-ref (can't remember exactly what APIs are available atm, but worst-case it's a match with bcx.load(llref) for Ref(llref)).

[nagisa]

Why common::is_immediate_type returns false here? Can we somehow unify the codepath that figure out expected immediate-ness of return value in signature and the codepath which does actual translation?

---

Or actually, why is it decided that the value ought to be returned by value? Its a 64 bit return on a 32 bit target. Seems sketchy?

[eddyb]

Both the ABI and the immediate check are correct IMO.

The problem isn't that they don't agree, the problem is that we have code that incorrectly assumes that they always do.

The ABI rules can be weird and we might even end up supporting several conflicting calling convention ABIs per platform, so we should just do the load there instead of trying to force it to be immediate.

[nikomatsakis]

@eddyb I haven't really looked at the code in question, but do you (or @nagisa) have a fix in mind?

[eddyb]

Yes, @Mark-Simulacrum has just started playing with it. The short version is "always load if you need an immediate instead of panicking".

[nikomatsakis]

triage: P-high