String literals: a raw CR is a line ending, not content

[revarbat]

Reported as BelfrySCAD#404 — string continuation retaining newlines. The newline half was already fixed in #150; this is the CR that was left behind.

The remaining bug

A string wrapped across two source lines drops the newline and keeps the next line's indentation. A \ continuation over CRLF already took the whole line ending. A bare continuation in a CRLF file was the one path still keeping the CR, so the same source had different content depending on which machine saved it:

echo(len("ab⏎cd"));	LF file	CRLF file
before	4	5
after	4	4

The stray CR is invisible in every echo and every exported label, which is what makes it worth fixing rather than documenting.

Why diverge from the reference

This is the reference's behaviour — its lexer's <cond_string> \n rule only advances the line counter, so the CR falls through to . and is appended — but it isn't behaviour worth reproducing. A raw CR in source is a line ending in every real file (CRLF on Windows, a lone CR on a pre-OSX Mac), and a script that wants a real CR writes \r, which still works. Upstream reached the same conclusion for the \-continuation case in openscad/openscad@dabdc41d6 ("Fix string line continuation regression", 2026-08-10).

The change

unescapeStringLiteral drops CR wherever it already dropped LF. That also collapses the backslash-before-CRLF special case into the ordinary one, since a trailing LF is now dropped by the loop itself — net -4 lines.

Verification

• StringEscapes.* extended: ARawCarriageReturnStandsForItself becomes ARawCarriageReturnIsALineEndingToo, covering CRLF, lone CR, kept indentation, and \r still producing a real CR.
• Full C++ suite: 1257 passed.
• tests/test_python_bindings.py: 42 passed.
• End to end on real CRLF and LF files through the CLI: both now echo 4/4, previously 5/4.

🤖 Generated with Claude Code

https://claude.ai/code/session_01JFTVMTH6yEktHDPF5csksb