The same Equivalent() call translates or not based on existence of other Equivalent() etc calls
duncand opened this issue · comments
For many different routines, whether or not the Translator succeeds in parsing
a routine call varies only on whether a separate call to the same routine
exists with different arguments further up in the same library.
The problem exists particularly with the generic equal/equivalent/not-equal
operators; just a few argument examples are given here to demonstrate the
problem, but it potentially happens with any pair of argument types.
The problem might also affect other operators having (Any,Any) signatures,
and it might affect other operators besides those.
Run the following CQL as a single block:
define x: {} = {}
define y: {} ~ {}
define ListEqABC123: { 'a', 'b', 'c' } = { 1, 2, 3 }
define ListEq123ABC: { 1, 2, 3 } = { 'a', 'b', 'c' }
define ListEq123String123: { 1, 2, 3 } = { '1', '2', '3' }
define EquivListABC123: { 'a', 'b', 'c' } ~ { 1, 2, 3 }
define EquivList123ABC: { 1, 2, 3 } ~ { 'a', 'b', 'c' }
define EquivList123String123: { 1, 2, 3 } ~ { '1', '2', '3' }
define ListNotEqABC123: { 'a', 'b', 'c' } != { 1, 2, 3 }
define ListNotEq123ABC: { 1, 2, 3 } != { 'a', 'b', 'c' }
define ListNotEq123String123: { 1, 2, 3 } != { '1', '2', '3' }
The actual result then is that the Translator succeeds and every statement
outputs a value, which happens to be null except for the first 2.
Next remove either or both of the first 2 lines and then run the CQL again.
If "x" is removed, then 6 of the last lines will fail to Translate,
citing an error like:
Could not resolve call to operator Equal with signature (list<System.Integer>,list<System.String>).
If "y" is removed, then the other 3 of the last lines will fail to Translate,
citing an error like:
Could not resolve call to operator Equivalent with signature (list<System.Integer>,list<System.String>)
Regardless of on what side of the fence one falls in regards to whether
they think Equivalent() etc with distinct argument types should fail to
Translate versus return false etc at runtime, this bug demonstrates a
serious issue in that the Translator isn't even consistent with itself;
the exact same statement having no external references to other expressions
should either Translate or not translate in exactly the same way no matter
what other statements the library contains.
These failing CQL Engine tests reflect this bug:
- CqlComparisonOperatorsTest.xml -> all 9 tests listed above
I also posted a duplicate ticket cqframework/clinical_quality_language#287 to clinical_quality_language since it is unequivocally the fault of the Translator component defined there, and is a high-impact bug. This first copy is with the CQL Engine so everything affecting Engine tests is logged in one place.
