Skip to content

Conversation

@mablr
Copy link
Contributor

@mablr mablr commented Oct 8, 2025

Closes #560

  • Updated LitKind::Number variant to handle negative numbers
  • Folding of neg unop expr into negative lit - with LitKind::Number set to negative - at ast lowering stage

status

  • Handle-1 as negative integer literal
  • Handle by peeling -(1) or -((2)) as negative integer literal as well
  • Handle-(-1) as unary op negate on negative integer literal (due to first item)
  • Handle-(1 + 2) as unary op negate, bin op of two positive int literals

todo

  • fix typeck handled by feat(sema): implicit integer conversions #564
  • add tests (testcases from initial issue) may be introduced instead in the PR mentioned above as the implicit integer conversion would be nice to have a ui test...

@mablr mablr marked this pull request as ready for review October 10, 2025 11:13
@mablr
Copy link
Contributor Author

mablr commented Oct 10, 2025

This is not finished yet, but I've changed the target of my modifications from parser to sema's ast lowering (actually simpler than I thought).

Please let me know if I'm on the good way 😃

@mablr
Copy link
Contributor Author

mablr commented Oct 10, 2025

Fyi @onbjerg I tried to apply locally to this PR your patch #564 for implicit integer conversions.

So this test case passes successfully the checks 👍 :

echo 'contract C { function f() public { int8 a = -((1)); int8 b = -1; uint8 c = -(-1);  } }' | cargo run -- -Ztypeck -

but for the following I guess explicit conversion/evaluation is needed:

echo 'contract C { function f() public { uint8 a = -(1-2); } }' | cargo run -- -Ztypeck -

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

Successfully merging this pull request may close these issues.

IntLiteral always has negative == false

2 participants