fix: two rules that ignored they were writing expression source (#340, #341)

[livingstaccato]

Fixes #340.
Fixes #341.

What

SerializationContext.inside_dollar_string tells a rule that the text it is producing is part of an expression rather than a value handed to the caller. StringRule checks it and keeps its quotes, for the obvious reason: upper("x") becoming upper(x) asks for a variable nobody declared. Two rules did not check it.

#340 — a heredoc argument was spliced in bare.

loads("a = upper(<<E\nx\nE\n)\n", serialization_options=value)["a"]
# '${upper(x)}'   ← a reference, not a string

The quoted equivalent one line away was already correct (${upper("x")}). With a multi-line body it was worse: raw newlines went into expression source that then did not parse.

#341 — a string literal inside a directive lost its delimiters.

loads('a = "%{ if x == \\"y\\" }t%{ endif }"\n', serialization_options=value)["a"]
# '%{ if x == y }t%{ endif }'   ← compares against a variable

TemplateStringRule only ever appears inside %{ ... }, where the text is expression source and the quotes belong to a literal written in it.

One thing that changes beyond the issues

With preserve_heredocs on, a heredoc inside an expression is now left as itself rather than wrapped in quotes. Quoting it put raw newlines inside a quoted string, which OpenTofu rejects with "Invalid multi-line string"; as a heredoc it is a legal argument, and trimspace(<<EOF\n hi \nEOF\n) evaluates to "hi". One existing test pinned the quoted form and now states this, with the reason.

Ground truth

OpenTofu v1.12.5: upper(<<EOT\nx\nEOT\n) evaluates to "X\n", so the argument is a string; a directive literal is written with plain quotes, "%{ if local.x == "y" }t%{ endif }", and evaluates to "t". That plain spelling round-trips here unchanged, and is asserted so it stays that way.

One divergence this does not touch: the grammar accepts \"y\" inside a directive, which OpenTofu rejects with "Invalid character". That is a separate defect, filed as #353. This PR only stops the value form from mangling that spelling into a reference; it neither blesses nor removes it.

Merging

It touches the same code as #335 (hcl2/rules/strings.py), #346 (hcl2/rules/strings.py), #352 (hcl2/rules/strings.py), #354 (hcl2/rules/strings.py). Whichever of those lands first, this one needs a rebase rather than a merge — the overlaps are real edits to the same methods, not adjacent lines, so resolving them by hand risks losing one of the two fixes. Say the word and I will rebase and re-run the suite.

---

This pull request, and the investigation behind it, were produced by an AI assistant (Claude) working on behalf of the author. Please review with that provenance in mind.

[livingstaccato]

Please hold off on merging this one for now — I want to do another review pass over it before it goes in. Opened as a draft for that reason; I will mark it ready and say so here once I am done.

[livingstaccato]

Review pass done, so the hold above no longer applies — this is ready for review now.

Rebased on current main; GitHub reports it mergeable as it stands.

_{🤖 Drafted with Claude Code.}

[livingstaccato]

Brought up to date with current main (0f74596) — GitHub had this flagged as
conflicting, which was only CHANGELOG.md and the merge=union driver that the
web UI does not honour. This one conflicts with #335, #346, #352 and #354 (hcl2/rules/strings.py)
rather than with main; the second note is about this PR's expectations.

Merge order. Eight of the twelve open PRs apply to main in sequence with no
conflict at all — verified by merging each and running the suite, not by
inspection:

#332 → #334 → #335 → #345 → #346 → #349 → #352 → #354

(1552 → 1563 → 1591 → 1627 → 1671 → 1696 → 1703 → 1711 passing, from a 1534
baseline; each adds its own tests.) The other four — #333, #348, #350, #351 —
conflict with siblings rather than with main, so no ordering avoids them.

#335 changes a value two of the others assert on. It makes a heredoc body
carry the newline that ends its last content line, matching what OpenTofu
evaluates:

from hcl2.utils import SerializationOptions
opts = SerializationOptions(strip_string_quotes=True, preserve_heredocs=False)
hcl2.loads("a = <<E\nx\nE\n", serialization_options=opts)["a"]

main alone:   'x'
main + #335:  'x\n'

#350 and #351 were written before that. Once #335 is in, their expectations need
the newline — in an integration carrying all twelve, every one of the 16
resulting failures was exactly that one character and nothing else. Worth knowing
because it presents as a regression and is not one.

A resolved integration of all twelve is on the fork if it is useful:
livingstaccato/python-hcl2:int/pyvider-hcl-9 — 1784 passing, ruff and mypy
clean. Not proposed as a PR; the twelve are more reviewable apart.

_{Drafted with the help of an LLM, working on behalf of the author.}