Add warning for integer literals exceeding 64-bit capacity in non-base-10 formats

[Copilot]

Long integer literals in hex/binary/octal formats are silently truncated to 64 bits, masking potential bugs when developers expect larger values.

Changes

compiler/lexer.nim:

• Set result.base early during first-stage parsing (enables proper warning context)
• Added overflow check for untyped integer literals (tkIntLit, tkUIntLit) after suffix determination
• Emit deprecation warning when digit count exceeds: 16 (hex), 64 (binary), 22 (octal)
• Explicitly typed literals unchanged—per manual spec, they wrap on overflow for bit-pattern use

tests/lexer/tinteger_literal_no_overflow.nim:

• Validates no false positives for valid-sized and explicitly-typed literals

Example

# Now warns:
let x = 0xFFFFFFFFFFFFFFFFF  # 17 hex digits
# Warning: number literal has too many digits; hexadecimal literals 
#          for 64-bit integers can have at most 16 digits

# Still valid:
let y = 0xFFFFFFFFFFFFFFFF   # Exactly 16 digits
let z = 0xFF'i8               # Typed literal, wraps to -1

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Long integer literal truncated without warning</issue_title>
<issue_description>### Nim Version

Nim Compiler Version 2.2.4 [MacOSX: arm64]
Compiled at 2025-07-15
Copyright (c) 2006-2025 by Andreas Rumpf

git hash: f7145dd
active boot switches: -d:release
[

Description

Long integer literals are truncated without warning, possibly to the machine int size

Example:

echo $sizeof 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff

Current Output

8

Expected Output

warning/error

Known Workarounds

When operating on large integers, e.g., when initializing uint256, do so from string rather from integer literal

Additional Information

No response</issue_description>

Comments on the Issue (you are @copilot in this section)

@ringabout > Literals must match the datatype, for example, 333'i8 is an invalid literal. Non-base-10 literals are used mainly for flags and bit pattern representations, therefore the checking is done on bit width and not on value range. Hence: 0b10000000'u8 == 0x80'u8 == 128, but, 0b10000000'i8 == 0x80'i8 == -1 instead of causing an overflow error. @ringabout > but, 0b10000000'i8 == 0x80'i8 == -1 instead of causing an overflow error.

In the manual, it says it returns -1 instead of causing an overflow error. Though we can give a warning for this if necessary.</comment_new>

• Fixes Long integer literal truncated without warning #25074

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[ringabout]

@copilot fixes it for all int types insteaf of restricting it to int/uint