Expose the parser's strict-comma mode: --strict-commas, strict_commas=

[revarbat]

Evaluator half of BelfrySCAD#362. Bumps the parser submodule to v1.2.0 (openscad_cpp_parser#9), which added StrictCommaScope, and hands it to the three places that can ask for it:

openscad-cpp-evaluator --strict-commas
Evaluator.evaluate(path, vp, strict_commas=True)   # Python
oscad::StrictCommaScope                            # C++, from the parser

A trailing comma in a call argument list or a let/for assignment list becomes a syntax error, as OpenSCAD 2021.01 had it. A list literal's and a parameter declaration's are untouched — 2021.01 accepted both, and rejecting them would fail files it loads. The measured table is in the parser PR.

The scope is constructed on the parsing thread

Not set from Python before the call. It's thread-local in the parser, and a host that evaluates on a worker thread — which BelfrySCAD does for every render — would otherwise set the mode on the main thread, parse on another, and silently get nothing. Costs nothing here and removes the trap outright.

Two binding tests, for a specific reason

The Python facade and the nanobind binding restate the same parameter list by hand, and the last argument added this way was silently dropped by the facade — split_components, which no C++ test could see because the C++ suite never enters Python. That's what test_export_model_facade_accepts_split_components exists for.

So: one test that the flag reaches the parser at all, and one that it doesn't leak into the next evaluation.

1830 C++ tests and 34 Python binding tests pass.

Verified end to end through the CLI:

script	default	--strict-commas
cube(1,);	accept	ERROR
y = let(x=1,) x;	accept	ERROR
a = [2,4,];	accept	accept

🤖 Generated with Claude Code

https://claude.ai/code/session_01AzS79GLeG7LpYB6KjgDbi1