Strange error in if expression using += about cone

[jondgoodwin]

This is surely a stupid bug that I can hopefully fix without much effort. Appreciate you letting me know.

[jondgoodwin]

Update: this turns out to be a rather gnarly bug,. It may be stupid, but it is not easy to diagnose or fix.

First off, the error message is deceptive. The real bug is not an initialization error during data flow analysis.

The real error actually lives in the type checking pass. a += 1 has special handling as an "opassign" operator, where the left hand is treated as an lval.

• The first attempt lowers it to i32::+=(&mut a, 1).
• Since i32 does not have a '+=' method, it gets lowered again to a block like this: {imm temp = &mut a; *temp = *temp + 1}.

That lowering is sometimes not working correctly and getting abbreviated to only the second statement in the block. This abbreviation means that data flow analysis never notices temp being initialized (since it does not see temp getting declared with an initial value). And thus we get the error.

The opassign lowering logic in fncall is a safety hazard. I need to refactor it to work in a more inclusive straightforward way. This will take more effort and experimentation to get right. Still on my queue to finish up....

[jondgoodwin]

The opassign logic has been refactored to be easier to follow and safer.

It turns out several other bugs were also in play:

• A generation bug on intrinsic handling of double floats
• Bad logic in block type checking that pretended to inject a blockret, but didn't, causing block to misplace the lowered last expression (<-- the real reason for the reported bug)

All bugs have been fixed. Please close if you confirm this issue is now solved.

[Ivo-Balbaert]

Great, it works!