Fix equality of empty lists ({} = {} -> true) (#1721) - #1793
Closed
c-schuler wants to merge 4 commits into
Closed
Conversation
Related IssuesThe following open issues may be related to this PR:
|
|
Formatting check succeeded! |
Contributor
Author
|
Closing this as the cql-tests test is found to be in error: cqframework/cql-tests#129 |
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.
Problem
{} = {}returnednullinstead oftrue(and{} != {}returnednullinstead offalse). Per the spec, the=operator for lists returns true when the lists "have the same elements by value, in the same order" — two empty lists are vacuously equal.Root cause
EqualEvaluator.listsEqualhad an over-broad guard that returnednullwhenever either list was empty:This conflated "empty list" with "null". It was introduced in the Equal/Equivalent refactor (#1668). The existing loop/tail logic already handles empty lists correctly, so the guard was both unnecessary and wrong.
Fix
Removed the guard. Behavior is now:
Null-element handling is unchanged
The removed guard only fired for empty lists (zero elements); lists that contain nulls have hasNext() == true, so they were never affected. The existing element-wise logic continues to implement the spec's two clauses correctly - a null matched against another null is equal, a null against a non-null (or a trailing null on a length mismatch) yields null:
EquivalentEvaluator.listEquivalent has no analogous guard, so this bug was isolated to EqualEvaluator.
Engine test corrections
The engine's own tests asserted the buggy null for {} = {}; updated to match the conformance suite (EqualEmptyListAndEmptyList -> true, NotEqualEmptyAndEmpty -> false):
Validation
Fixes #1721