Add support for inline if expressions#449
Open
Daniel-Tr wants to merge 2 commits into
Open
Conversation
added 2 commits
July 23, 2026 14:40
…olution and control flow modeling The LUB computation picked whichever branch converted more cleanly to the other, which can only ever return one of the two branch types. The Delphi compiler's actual promotion rules sometimes resolve to a type that is neither branch's type (e.g. Byte/Word -> Integer), and never derive a common ancestor for sibling class types. Replace it with a table-driven implementation matching the compiler's documented behavior, verified against dcc64 output. Also model the expression as a real CFG branch (only one side is actually evaluated at runtime) instead of a flat both-sides-evaluated node, count it in cyclomatic/cognitive complexity like an if statement, and rename getConditionExpression to getGuardExpression for consistency with IfStatementNode.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Resolves #407.
Delphi 13 adds an
if <cond> then <expr> else <expr>conditionalexpression. This adds parsing for it, models it as a proper branch in
the CFG (only one side actually runs at runtime, so it isn't
evaluated the way a range or array-constructor expression is), and
resolves its type as the compiler's least-upper-bound of the two
branches.
The LUB isn't a "pick whichever branch converts better" comparison -
that can only ever return one of the two input types, but Delphi's
actual promotion rules sometimes land on neither (e.g.
ByteandWordresolve toInteger, notWord), and unrelated classbranches need a common-ancestor walk rather than a closest-match
pick.
ExpressionTypeResolverTestencodes the promotion rules as atable, with every expected result checked against
dcc64directly(assigning the expression to an incompatible variable and reading the
type off the resulting E2010 error - see the class comment) rather
than inferred from the existing overload-resolution machinery.
Also counts as a decision point in cyclomatic/cognitive complexity,
same as an
ifstatement.This change has mostly been created by Claude and reviewed manually.
We compiled, installed, and beta-tested this change in our CI environment
against productive code (that fails with the current published version).