Skip to content

feat(typeck): support negative integer literal coercion #648

Merged
onbjerg merged 1 commit intomainfrom
onbjerg/int-literal-negative
Dec 22, 2025
Merged

feat(typeck): support negative integer literal coercion #648
onbjerg merged 1 commit intomainfrom
onbjerg/int-literal-negative

Conversation

@onbjerg
Copy link
Copy Markdown
Contributor

@onbjerg onbjerg commented Dec 17, 2025

Implement proper handling of negative integer literals in the type checker. Previously, negative literals like -42 were broken because:

  1. The parser represents them as unary negation applied to a positive literal, so type_of_lit only sees the positive value
  2. The negativity flag in IntLiteral was always false

This commit fixes the issue by:

  • Allowing unary negation on IntLiteral types (they can always be negated since the result is just a negative literal)
  • Propagating the negativity flag when applying unary negation to an IntLiteral, flipping neg from false to true
  • Not propagating the expected type through negation when targeting signed types, to avoid premature type mismatch errors on the inner expression

Also simplifies the coercion rule to use strict inequality for both positive and negative literals, since TypeSize rounding means we can't reliably distinguish edge cases in either direction.

On top of #647

Supercedes #566 (will mark @mablr as a co-author to commend effort) and closes #560 (closes #566)

Stack:

@onbjerg onbjerg requested a review from DaniPopes as a code owner December 17, 2025 00:57
@onbjerg onbjerg added C-enhancement Category: an issue proposing an enhancement or a PR with one A-sema Area: semantic analysis labels Dec 17, 2025
DaniPopes pushed a commit that referenced this pull request Dec 22, 2025
This enables distinguishing edge cases like 127 (fits in int8) from 128
(doesn't fit), which is needed for correct implicit and explicit integer
conversions.

- Changed internal storage from `u8` (bytes 0-32) to `u16` (bits 0-256)
- `TypeSize::new()` now takes bits directly
- Added `new_fb_bytes()` for fixed-bytes types that take byte counts
- `bits()` returns stored value, `bytes()` computes `ceil(bits/8)`
- `mk_ty_int_literal` no longer rounds to multiples of 8

Closes #650

Unblocks #647 #648 #649
@onbjerg onbjerg force-pushed the onbjerg/int-literal-negative branch from addc964 to e4c688d Compare December 22, 2025 19:12
@onbjerg onbjerg force-pushed the onbjerg/int-literal-coercion branch from 1e5aea6 to 92db371 Compare December 22, 2025 19:12
@onbjerg onbjerg force-pushed the onbjerg/int-literal-negative branch from e4c688d to d621ddf Compare December 22, 2025 19:13
@onbjerg onbjerg force-pushed the onbjerg/int-literal-coercion branch from 92db371 to 54d1f87 Compare December 22, 2025 19:13
Base automatically changed from onbjerg/int-literal-coercion to main December 22, 2025 19:35
onbjerg added a commit that referenced this pull request Dec 22, 2025
Add implicit type coercion for integer literals (IntLiteral) to typed
integers (uint/int). The coercion rules are:

- IntLiteral -> uint: Allowed if the literal is non-negative and fits in
the target size (size.bits() <= target.bits())

- IntLiteral -> int: Allowed with strict inequality (size.bits() <
target.bits()) for non-negative values due to TypeSize rounding, and
non-strict for negative values

TypeSize stores ceil(bit_len/8), so int_literal[1] covers 0-255. This
means we can't distinguish edge cases like 127 (fits in int8) from 128
(doesn't fit), so we conservatively require int16+ for int_literal[1].

Note: Negative literal support requires additional work in the type
checker to propagate negativity through unary negation. This is provided
in a follow up.

Supercedes #564 and closes #627
(closes #564)

Stack:

- #647 (this)
- #648 
- #649
Implement proper handling of negative integer literals in the type
checker. Previously, negative literals like -42 were broken because:

1. The parser represents them as unary negation applied to a positive
   literal, so type_of_lit only sees the positive value
2. The negativity flag in IntLiteral was always false

This commit fixes the issue by:

- Allowing unary negation on IntLiteral types (they can always be
  negated since the result is just a negative literal)
- Propagating the negativity flag when applying unary negation to an
  IntLiteral, flipping neg from false to true
- Not propagating the expected type through negation when targeting
  signed types, to avoid premature type mismatch errors on the inner
  expression

Also simplifies the coercion rule to use strict inequality for both
positive and negative literals, since TypeSize rounding means we can't
reliably distinguish edge cases in either direction.
@onbjerg onbjerg force-pushed the onbjerg/int-literal-negative branch from d621ddf to 6860eb9 Compare December 22, 2025 19:36
@onbjerg onbjerg enabled auto-merge (squash) December 22, 2025 19:38
@onbjerg onbjerg merged commit 644ccf2 into main Dec 22, 2025
18 checks passed
@onbjerg onbjerg deleted the onbjerg/int-literal-negative branch December 22, 2025 19:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-sema Area: semantic analysis C-enhancement Category: an issue proposing an enhancement or a PR with one

Projects

None yet

Development

Successfully merging this pull request may close these issues.

IntLiteral always has negative == false

2 participants