range_010
range_011
range_012

Those 3 tests are failing in 0068 suite test.

After deeper investigation, it turns out that there are different problems related to this ticket.

1
The TCK range tests (e.g. (> 10) = (10..null) (=10) = [10..10]) seems to verify that the expression is different even if its evaluation is the same.
OUr code

1. translate the (> 10) = (10..null) to an InfixOpNode
2. evaluate left and right part of the expression (inside EqExecutor)
3. compares them

So, first of all I think there is an issue in the InfixOpNode/EqExecutor, that, in this case, should verify if the expression is the same, and not if its evaluation is the same.

(> 10) = (10..null) -> FALSE succeed "by chance" because we introduced the undefined, so the range returned is (10..undefined) , but actually the behavior is wrong (replacing (10..null) with (10..undefined) demonstrates it)

2
(=10) = (=10) -> TRUE fails because (=10) is not translated to Range, and when the code enter BooleanEvalHelper.compare, there is not an "if " dealing with UnaryTestImpl, and returns null

Problem 2 could be solved implementing conversion of (=10) to [10..10] , but then problem 1 ((=10) = [10..10] -> FALSE )

would still be there because, during execution, left and right side would be evaluated to same object before comparison.

@baldimir @yesamer wdyt ?

I made modification in my own branch, and I have fixed some use cases.
Anyway, a new issue arise, namely

Expression
= null
Test
context.set("in1", null);

Currently, the expression is converted to UnaryTestNode
Then, at execution, the utEqualSemantic method is invoked, that does not check if the right object is ´null´ (as in this case) so it returns true (because both left and right are null)

With my modification, = null is translated to Range, but then the createInUnaryTest method is invoked. In that case, if the input is null (as in the current test) the method immediately returns false, and the test fails.
Beside, if the input is different then null, then the RangeImpl.includes method is invoked, that returns null if the parameter is null.
So, on one side it is not clear if = null should be translated to [null .. null] or [undefined .. undefined]; on the other side, we should review the behavior of UnaryTestNode.createInUnaryTest when the input is null (I don't know why it is different then utEqualSemantic)

@baldimir @yesamer