Fix preprocessor numeric literal parsing to avoid incorrect partial matches

[mvaligursky]

Fixes an edge case where expressions starting with numbers could be incorrectly parsed as numeric literals.

Problem

The numeric literal check using parseFloat(expr) could produce incorrect results for expressions containing comparison operators. For example, #if 3 == 3 would be parsed as parseFloat("3 == 3") which returns 3 (parseFloat stops at the first non-numeric character), causing the expression to incorrectly evaluate to true.

Solution

Use a strict regex (/^\d+(?:\.\d+)?$/) that only matches pure numeric literals, ensuring expressions like 3 == 3 or 0 != 1 don't get incorrectly parsed as numbers.

Test Plan

• Added 3 edge case tests (#if 3 == 3, #if 0 != 1, #if 5 > 3)
• All 52 preprocessor tests pass

[Copilot]

Pull request overview

This PR fixes a bug in the preprocessor's numeric literal parsing that could cause expressions starting with numbers to be incorrectly parsed as pure numeric values.

Changes:

• Added a strict regex pattern (NUMERIC_LITERAL) to match only pure numeric literals (integers and decimals)
• Replaced parseFloat() check with the new regex test to prevent partial string parsing
• Added three test cases to verify expressions like #if 3 == 3 are correctly rejected rather than incorrectly evaluated

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
src/core/preprocessor.js	Introduced NUMERIC_LITERAL regex and updated evaluateAtomicExpression() to use strict pattern matching instead of parseFloat()
test/core/preprocessor.test.mjs	Added edge case tests for numeric expressions with comparison operators that should evaluate to false

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.