Add CallExpression, ExpressionStatement and ConditionalExpression

[matt-edmondson]

Closes #55.

The gap

The AST could describe a declaration in a language-agnostic way and a body only if that body was an operator applied to operands. There was no way to say a call, and no statement node for an expression evaluated for its effect, so a void call — assert(...), list.clear() — could not be said at all.

Anything beyond a return of a literal, a variable, an operator application or a constructor call had to be handed to VariableReference as target-language text. That text passes through every generator unchanged, so it is right in at most one language — which makes a tree built for one language untranslatable to another, and that is the premise of the library.

What this adds

CallExpression — a callee, an optional receiver, and an argument list. The receiver is modelled separately rather than folded into the callee because the receiver is the part the languages disagree about:

Target	CallExpression(receiver: point, callee: "translate", args: [dx, dy])
C#, C++, Python, JavaScript, Rust	point.translate(dx, dy)
C	translate(&point, dx, dy)

C has no member functions and lowers one to a free function taking the instance, which is the transformation CGenerator already performs on the declaration (Point_translate(Point* self, …)). Modelling the receiver is what lets the call site follow the declaration it was emitted for.

ExpressionStatement — an expression evaluated for its effect. Every generator ends it the way it ends a return or an assignment, so Python's ends at the newline and the other five at a semicolon without either being a special case.

ConditionalExpression — a choice between two values, and three spellings across the six targets:

Target	Spelling
C#, C++, C, JavaScript	(ready ? go : wait)
Python	(go if ready else wait)
Rust	(if ready { go } else { wait })

Rust is the strongest argument for this being a node. Python only reorders the operands, so hand-written ?: there is merely unidiomatic — in Rust it does not parse at all, because Rust has no ternary operator and makes if an expression instead.

The callee-naming question, settled

#55 flagged this as needing a decision before the node landed: sqrt is std::sqrt, Math.Sqrt, math.sqrt and f64::sqrt across the targets.

Callee is text and is written verbatim. There is no shared idea underneath those spellings for the AST to hold — the way there is underneath a type, which is why TypeReference is structure. Choosing the name stays the caller's, exactly as SourceFile.Imports and CompileTimeAssertion.Condition already are. What the AST carries is the shape of the call, and the shape is what the generators need in order to disagree about it.

The reasoning is written down on the node itself rather than only here.

One documented limitation

C takes the receiver's address, because the self parameter it generates is a pointer. That assumes the receiver is an instance rather than already a pointer to one — an assumption, not a deduction, since a CallExpression knows the receiver's spelling and not its type.

It is the assumption worth making: taking the address is the only one of the two a caller cannot write for itself (the AST has no address-of operator), and what this generator emits elsewhere is instances. A caller holding a pointer spells the call as a free function and passes the pointer as an ordinary argument. This is stated in CGenerator's remarks rather than left to be discovered.

Coverage

Each node is wired into AstSchema (slots, children, attach, replace, detach, describe), AstFields (a call's callee is editable from the inspector — deliberately not repeating #48), AstNodeCatalog, the YAML serializer and deserializer, and all six generators.

TryAttachAt is split into three along the way — operand slots, statement/declaration slots, sequences — because one switch over every slot the AST has exceeds what CA1502 accepts. That is the same split the file already makes elsewhere for the same reason.

50 new tests. Structure, null rejection, deep clone, generation in all six languages, YAML round-trip, and the graph-side slot/field/palette wiring.

Both risky claims are checked by compiling rather than by pinning a spelling — whether generated code is well formed is a question about types, which is not visible in the text.

C, proving the receiver lowering reaches the member function the same generator emitted:

int Counter_value(const Counter* self) { return 0; }

int Counter_span(void)
{
    Counter here = { .count = 0 };
    Counter_value(&here);
    return Counter_value(&here);
}

under -std=c11 -Wall -Wextra -pedantic. And Rust, proving the void call and the if-expression:

pub fn pick(&mut self) -> i32 {
    self.shift(1);
    return (if (self.x > self.y) { self.x } else { self.y });
}

under rustc --edition 2021.

Merged with main

Main gained a sixth target language (Rust, #56) while this branch was open, which was more than a textual conflict. RustGenerator derives from StandardLanguageGenerator, so it inherited the three new dispatch cases — two of the three defaults were already correct for it, and the third was not:

• A member call and a statement terminator needed no override; the tests now assert that rather than assume it.
• A conditional did. The inherited ?: would not have compiled. RustGenerator now writes an if expression, parenthesised because an if at the start of a statement parses as a statement, which would silently discard the branches' values.

The C call test is ported onto ToolchainHarness, which main extracted in the same window. Language counts in the prose are corrected throughout.

Deferred

Throw expressions are left out, as #55 suggested: C++ and C diverge sharply, and there is no consumer for it yet.

Verification

• dotnet build and dotnet build -c Release — clean, 0 warnings, both target frameworks
• Full suite on the merged tree: 630 passed, 0 failed
• Both compile tests ran against real cc and rustc rather than reporting inconclusive
• No suppressions added

🤖 Generated with Claude Code

https://claude.ai/code/session_01QGCMUrT3jBgmANHNHcPmBf

[sonarqubecloud]

Quality Gate passed

Issues
24 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud