Review fix legend pure compiler mismatch - #4997
Closed
FeruzGS wants to merge 3 commits into
Closed
Conversation
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
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.
Purpose
Aligns Legend Java compiler's handling of single-element collection literals
(
[$x]) with Pure's own compiler. Previously, wrapping any non-[1]variablein brackets — e.g.
[$optional]where$optional : String[0..1]— wasrejected by
ValueSpecificationBuilder.visit(Collection)with:Reproduction (before fix)
Pure IDE: compiles
Legend compiler: [Error] "Collection element must have a multiplicity [1] ... [0..1]"
Fix
In
ValueSpecificationBuilder.visit(Collection):Guard relaxed to multi-element case only. The
[1]-only element rulenow fires only when
collection.values.size() > 1. Single-element literals[$x]are accepted regardless of the wrapped variable's multiplicity —they act as a semantically transparent wrapper (Pure has no nested
collections;
[$x]and$xproduce the same flat shape).Effective multiplicity propagated truthfully. For a 1-element literal
wrapping a non-
[1]variable, the resultingInstanceValue's multiplicityis set to the inner variable's multiplicity (not the parser-supplied count
of
1). This ensures downstream consumers see the real runtime cardinalityrather than being told "exactly 1" when the value could be
[0..1]or[*].Unwrap guarded by
isExactlyOne. The value-compaction step (unwrap asingle-element
InstanceValueinto its raw first value) now only fireswhen the element's multiplicity is exactly
[1].For every collection shape that compiled before this change, the resulting
M3 graph is byte-identical. Only newly-accepted shapes produce a new graph,
and that graph matches what Pure's own compiler produces from equivalent
.puresource.Patterns unblocked
All five surface syntaxes that lower to
visit(Collection):Function arguments —
concatenate([$opt], $many)(the ticket case).ifbranches —if($cond, | [$opt], | []).Class constructor slots —
^Foo(xs = [$opt])wherexs : String[*].Pipeline steps —
$people->filter(p | [$p.middleName]->isNotEmpty()).Invariant preserved
Multi-element literals
[a, b, ...]still require every element to be[1].This is the invariant that parser-rewritten binary operators rely on:
Files changed
ValueSpecificationBuilder.java— the fix (+isExactlyOnehelper).TestDomainCompilationFromGrammar.java— 5 regression tests.