[matt-edmondson]

Fixes #183
Fixes #184

The triage on both issues suggested fixing them together, since #184's guard is the one #183 moves into validation.

#183: an empty expression body truncated its class

RenderExpression's empty-expression check only ran when the property itself was written. Inside a class, that happens after the class header and the members before it, and disposing the body scope then closes the class. The result was a well-formed class missing the property and every member after it.

• TemplateBase.Validate now takes the CodeBlocker it is checking for (internal, so the public API is unchanged). That writer only supplies the indent and line terminator the callback is rendered with. Nothing is written to it.
• PropertyTemplate.Validate(codeBlocker) renders the expression body, or each expression accessor's body, and throws the same InvalidOperationException that WriteTo would.
• ClassTemplate, AddClasses and AddSourceFile pass the writer down, so they refuse the whole type or file before writing anything, as Check a class's members before writing any of it [patch] #169 does for the other member checks.
• Standalone PropertyTemplate.WriteTo still renders each expression once. Inside a class the callback now runs twice, once to validate and once to write. The remarks on Validate say so.

#184: a comment- or directive-only expression rendered => ;

RenderExpression now throws when !HasCode(lines) rather than only when every line is blank. A body that writes only // ..., or only #if/#endif, gets the #175 exception. An expression with a trailing comment (#144), or real code wrapped in directives (#158), renders as before.

Tests

• 8 new tests in TemplateTests. They cover an empty or comment-only expression body and expression accessor inside a class (nothing written), the same through AddSourceFile, and comment-only and directive-only bodies on a standalone property and accessor. A regression check confirms the An expression body whose last line ends in a // comment gets its semicolon inside the comment: public int P => x // note; does not compile (CS1002) #144 and An expression body containing #if/#else/#endif renders int P => #if DEBUG and #endif;, which doesn't compile #158 shapes still render.
• With the library change reverted, all 8 new tests fail. With it, the full suite passes: 338 tests.
• The local Sonar run (.sonarlint/sonar-local.props) reports nothing beyond the existing S2699 findings.

Note: the triage on #183 points out that open PR #182 also touches TemplateRendering. The two edit different methods, and this branch rebases cleanly on current main.

---

Generated by Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud