Report the syntax error instead of dying on the half-built tree (#813)

[Rafael-SOWNet]

Closes #813.

What was wrong

ANTLR reports a syntax error to the listener and then recovers, carrying on with a rule context whose value was never assigned. The grammar's action for provided runs anyway:

_localctx.value = _localctx.value.Provided(_localctx.pred.value);   // AngouriMathParser.cs:1549

so the parse came down with a raw NullReferenceException before ParseSilent ever read the error already sitting in writer.errors.

That last part is the whole fix. The error was detected the entire time; the parser just died before anyone looked at it.

try { parser.Parse(); }
catch (Exception) when (writer.errors.Count > 0)
{
    return new Failure<ReasonWhyParsingFailed>(writer.errors[0]);
}

Reading the recorded error is the honest answer — the input really was invalid, and a caller is owed an exception under AngouriMathBaseException, as Docs/Usage/Exceptions.md promises. The guard is what makes this safe rather than a blanket swallow: where the parser throws with nothing recorded against the input, the exception is ours and it keeps propagating. A bug of ours cannot be laundered into a syntax error.

Measured

Each of these was a NullReferenceException on 61de353b:

input	now
(1 provided x > 0, 2)	UnhandledParseException: line 1:17 no viable alternative
(a provided b, c)	line 1:13
(1 provided x > 0, 2, 3)	line 1:17
(1, 2 provided x > 0)	line 1:2
(1 provided x > 0, 2 provided x < 0)	line 1:17

The last two are wider than the issue reported: a provided after the comma crashes too, so the trigger is a provided anywhere in a parenthesised comma list, not only one followed by a comma.

A correction to the issue

#813 says the piecewise forms from #326 "do not parse either". That is wrong, and I wrote it. All three documented shapes parse:

piecewise(1 provided x > 0, 2)                     ->  piecewise(1 provided (x > 0), 2 provided True)
piecewise(1 provided x > 0, 2 provided x < 0)      ->  parses
piecewise(1 provided x > 0, 2 provided x < 0, 3)   ->  piecewise(..., 3 provided True)

Only the capitalised Piecewise( fails, as an unknown name followed by a bracket — which is #733, not this. I tested with the capitalisation used in #326's prose and drew the wrong conclusion from it.

So the grammar does have a rule for the comma list of provided; what has no rule is that list without a piecewise in front of it, and that is exactly what the crash was hiding. The tests now pin the working forms so the fix cannot be mistaken for refusing the construct.

Tests

5828 passing, 0 failed, 14 skipped. F# 130 passing.

Three groups added to FromStringTest: the five crashing inputs with their error positions; the provided and piecewise forms that must keep parsing; and a broader check that a malformed input is refused by this library's own exception rather than a framework one — which is the property the issue is actually about, and which nothing was asserting.

Not in scope

What the piecewise syntax should be is #326, still open and marked Opinions wanted. Fixing the crash did not need that settled, and this does not settle it.

🤖 Generated with Claude Code