Repository navigation
[MIR] Phantom unit write after return #31472
Description
EDIT: I was confused about the issue
pub fn foo(mut value: u64) -> usize {
return 0;
}fn(arg0: u64) -> usize {
let mut var0: u64; // value
let mut tmp0: ();
let mut tmp1: ();
bb0: {
var0 = arg0;
return = const 0;
goto -> bb1;
}
bb1: {
return;
}
bb2: {
drop(tmp0) -> bb3;
}
bb3: {
return = ();
goto -> bb1;
}
}
Activity
[-][MIR] Phantom unit write with loop [/-][+][MIR] Phantom unit write after return[/+]arielb1 commentedon Feb 7, 2016
The write here is the empty write at the end of a block - which should not exist if the block is diverging.
Unclear whether we should not create the (ill-formed) write when building or remove it in post-processing.
nagisa commentedon Feb 7, 2016
NB: This write gets removed by simplifycfg (you need to comment the pass out to reproduce the issue).
arielb1 commentedon Feb 7, 2016
This would still pose a problem to analysis passes that want to run before SimplifyCfg. I am adding an early pass for my MIR typeck PR to ameliorate this problem.
nagisa commentedon Feb 7, 2016
Likely caused by this
arielb1 commentedon Feb 7, 2016
The root cause of the problem is that typeck allows "diverging" blocks to have any kind of return value instead of requiring it to be MIR. I think that clearing the diverging blocks in a post-pass is a better strategy than detecting diverging blocks in HAIR.
solson commentedon Feb 19, 2016
Maybe we should only emit what @nagisa linked to when the actual type of the block is unit?
Generally, a missing final expression doesn't necessarily mean
()could be inserted, e.g.:EDIT: Do we want to omit the unit write even for a block of type unit if the block is diverging? Then what I said wouldn't help.
varkor commentedon Apr 12, 2018
As far as I can tell, this was fixed by #47746, where the trailing unit is only added if the return type of the function is the unit type.