fix: parse negative and exponent number literals in all four clients

[diegolopezrm]

Follow-up to the review discussion in #2497, where you said this deserved its own PR.

The bug isn't that negatives were rejected — it's that ${-1} parsed as a data binding to the path -1, because - is a valid path character. ${round(value: -1)} handed the function a path where the author wrote a number, and nothing reported it. Exponents were rejected outright.

Same grammar in all four now:

'-'? digits ('.' digits?)? ( ('e'|'E') ('+'|'-')? digits )?

A number starts only on a digit, or on - followed by a digit, so ${a-b} and ${-a} stay paths. ${1-2} stays an error.

One thing I added beyond the ask: an exponent that overflows is now rejected instead of returning infinity. All four produced Infinity for ${1e999} once exponents worked, and that's the same problem as the NaN we fixed in #2497 — a value JSON can't carry and no renderer can show.

Ten new cases in conformance/core/expressions.yaml pin the lot, including the three that have to stay distinguishable: ${-1}, ${a-b} and ${1e}.

I ran the four parsers over the same 16 inputs — negatives, exponents, hyphens in paths, overflow, and the forms that already worked. They agree on all 16. Before the overflow fix they disagreed on exactly one, ${1e999}, which is what turned it up.

Suites: dart test 342 passing, node --test 511, pytest 24, swift test 24. Analyzer, prettier and eslint clean.

This branches off #2497, since the conformance suite lands there. Happy to rebase onto main once that merges — or if you'd rather, I can drop the yaml cases here and add them separately.

[gemini-code-assist]

Code Review

This pull request standardizes the parsing of negative numbers and exponential notation in expression templates across the Python, Dart, TypeScript, and Swift SDKs, and introduces a shared conformance test suite to ensure consistent behavior. Two important issues were identified in the review: first, the Python implementation of parse_number_literal fails to advance past a leading minus sign, which will cause negative numbers to fail parsing; second, the Dart implementation should wrap num.parse in a try-catch block to prevent raw FormatException leaks when parsing extremely large integers that exceed 64-bit limits.

[gemini-code-assist]

In the Python implementation of parse_number_literal, the parser does not advance past the leading minus sign (-) if one is present. This is a critical discrepancy compared to the Dart, TypeScript, and Swift implementations, which all explicitly check for and advance past the minus sign at the start of the function.

Without this advancement, the subsequent while loop (which only consumes digits and dots) will not execute, resulting in an empty num_str (or a string containing only the minus sign if it wasn't consumed), which then fails the NUMBER_LITERAL regex match and raises a ValueError.

To fix this, please add the check to advance past the leading minus sign at the very beginning of parse_number_literal in Python:

    def parse_number_literal(self, scanner: Scanner) -> Union[int, float]:
        start = scanner.pos
        if scanner.peek() == "-":
            scanner.advance()
        while (
            self.is_digit(scanner.peek()) or scanner.peek() == "."
        ):
            scanner.advance()
        # ... rest of the function

[diegolopezrm]

It does advance past it — that's the first thing parse_number_literal does, two lines above the digit loop:

start = scanner.pos
if scanner.peek() == "-":
    scanner.advance()

Ran the four cases that matter to be sure:

${-1}                 -> [-1]
${round(value: -1)}   -> [{'call': 'round', 'args': {'value': -1}, ...}]
${a-b}                -> [{'path': 'a-b'}]
${-a}                 -> [{'path': '-a'}]

The suggested code matches what's already there.

[gemini-code-assist]

Although the _numberLiteral regex ensures the string has a valid numeric format, num.parse(text) can still throw a FormatException on some platforms (such as the Dart VM) if the parsed integer is extremely large and exceeds the 64-bit signed integer range (e.g., 99999999999999999999999999999999999999).

Since the CHANGELOG and design goals state that invalid/out-of-range number literals should throw A2uiExpressionError instead of leaking a raw FormatException, we should wrap the num.parse call in a try-catch block to safely catch any FormatException and throw an A2uiExpressionError instead.

Suggested change

	final num value = num.parse(text);
	final num value;
	try {
	value = num.parse(text);
	} on FormatException {
	throw A2uiExpressionError("Number literal is out of range: '$text'");
	}

[diegolopezrm]

num.parse falls back to a double when the digits don't fit an int, so it doesn't throw here:

${99999999999999999999999}  -> [1e+23]

Same result on the VM and under dart2js (dart test -p chrome), so there's no platform split to guard against. Literals that really are out of range are caught two lines below by the isFinite check — ${1e999} throws A2uiExpressionError.