Skip to content

TSLANG_ISSUES 15: unsigned integer types take part in numeric promotion - #570

Merged
ASDAlexander77 merged 1 commit into
mainfrom
fix-u64-promotion
Oct 13, 2026
Merged

ASDAlexander77 merged 1 commit into
mainfrom
fix-u64-promotion

Conversation

@ASDAlexander77

Copy link
Copy Markdown
Owner

TSLANG_ISSUES.md 15: u64 * <integer literal> was computed in 32 bits (2^32 * 2 == 0, d *= 256 wrapped).

numericPromotionOrder() had no unsigned types, so u64 * 2 found only the literal's s32. Each unsigned type now follows the signed and signless types of its width. Behaviour changes:

  • u64 op s32 / u64 op i32 is done in u64 (was s32/i32).
  • u64 op index is now u64 (was index).
  • an unsigned type paired with a signed or signless one of its own width still takes the other one (u32 * 1 is still s32).

Test: 00int64_mul_literal.ts (*, +, -, *=, and the byte-at-a-time word build from native_ts_graphics' stdString()).

Full Release suite with all six TSLANG_ISSUES fixes together: 4074/4074.

🤖 Generated with Claude Code

The promotion ladder had no unsigned types, so `u64 * 2` found only the
literal's s32 and was done in 32 bits: `2^32 * 2` was 0, and `d *= 256`
wrapped to 0 after four bytes. Each unsigned type now follows the signed
and signless types of its width (and comes before `index`), so
`u64 op s32` is done in u64; an unsigned type paired with a signed or
signless one of its own width still takes the other one.

Found in native_ts_graphics' stdString(), which cut every NVRHI debug
name to four characters (TSLANG_ISSUES.md 15).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@ASDAlexander77
ASDAlexander77 merged commit 1a7a1f5 into main Oct 13, 2026
2 checks passed
@ASDAlexander77
ASDAlexander77 deleted the fix-u64-promotion branch October 13, 2026 17:07
ASDAlexander77 added a commit that referenced this pull request Oct 13, 2026
13, 14, 15 and 18 are fixed by #572, #568, #570 and #569. For 16, `%` is
fixed by #571 and `/` stays a number. 17 is answered (`Deref(p[i]) = v`
stores) and its error names that form since #573. 5 and 6 stay open:
they are design questions, not bugs.

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
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.

1 participant