Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Strange error in if expression using += #30

Closed
Ivo-Balbaert opened this issue Oct 17, 2021 · 4 comments
Closed

Strange error in if expression using += #30

Ivo-Balbaert opened this issue Oct 17, 2021 · 4 comments

Comments

@Ivo-Balbaert
Copy link
Contributor

This code

fn main():
      mut a = 0
      if 42: a += 1

gives the Error 1048: This variable has not been initialized. There is no value to use.
-->
^--- test.cone:6:1
Unsuccessful compile: 1 errors, 0 warnings

However rewriting it as: if 42: a = a + 1
makes it work.

@jondgoodwin
Copy link
Owner

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

@jondgoodwin
Copy link
Owner

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
Copy link
Owner

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
Copy link
Contributor Author

Great, it works!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants