Some operator tests related to Null<T>

[Simn]

I'm not 100% positive that all these conform to the spec, but I'd like to get an overview of where we're at.

Related: #8367

[Aurel300]

f(...)	neko	eval	hl	java	jvm	cs	cpp	cppia	flash9
0 >= nullInt	.	.	F	F	.	F	.	.	.
0 < nullInt	.	.	.	.	.	.	.	.	.
0 <= nullInt	.	.	F	F	.	F	.	.	.
nullInt >= 0	.	.	F	F	.	F	.	.	.
nullInt <= 0	.	.	F	F	.	F	.	.	.
1 > nullInt	.	.	F	F	.	F	.	.	.
1 >= nullInt	.	.	F	F	.	F	.	.	.
1 < nullInt	.	.	.	.	.	.	.	.	.
1 <= nullInt	.	.	.	.	.	.	.	.	.
nullInt < 1	.	.	F	F	.	F	.	.	.
nullInt <= 1	.	.	F	F	.	F	.	.	.
-1 < nullInt	.	.	F	F	.	F	.	.	.
-1 <= nullInt	.	.	F	F	.	F	.	.	.
nullInt > -1	.	.	F	F	.	F	.	.	.
nullInt >= -1	.	.	F	F	.	F	.	.	.
0. >= nullFloat	.	.	F	F	.	F	.	.	.
0. < nullFloat	.	.	.	.	.	.	.	.	.
0. <= nullFloat	.	.	F	F	.	F	.	.	.
nullFloat >= 0.	.	.	F	F	.	F	.	.	.
nullFloat <= 0.	.	.	F	F	.	F	.	.	F
1. > nullFloat	.	.	F	F	.	F	.	.	F
1. >= nullFloat	.	.	F	F	.	F	.	.	F
1. < nullFloat	.	.	.	.	.	.	.	.	.
1. <= nullFloat	.	.	.	.	.	.	.	.	.
nullFloat < 1.	.	.	F	F	.	F	.	.	F
nullFloat <= 1.	.	.	F	F	.	F	.	.	F
-1. < nullFloat	.	.	F	F	.	F	.	.	F
-1. <= nullFloat	.	.	F	F	.	F	.	.	F
nullFloat > -1.	.	.	F	F	.	F	.	.	F
nullFloat >= -1.	.	.	F	F	.	F	.	.	F

(F for failure)

Flash 9 on Linux shows at least the failures above without displaying the total count; on OS X it shows the total number of failures (24) without displaying the specific lines … It is probably the same as HL.

[Simn]

@hughsando Could you check cppia? It should align with cpp.

@Aurel300 Could you resolve the conflict?

[Simn]

cppia confirmed fixed, I've updated the table.

I think we should fix Java/C#/HL, but I'm not sure how easy this is to fix. I'm tentatively setting this to 4.0. I'll look into Java myself, but I'll need help with C# and HL (@kLabz and @ncannasse).

[Simn]

Actually pinging @nadako as well because the flash behavior might bite them.

[Simn]

@waneck Any pointers to where this is handled? The problem here is that when doing Null<Int> >= Int, genjava generates haxe.lang.Runtime.toInt(lhs) >= rhs which leads to a 0 >= 0 comparison. We shouldn't apply this cast for comparison operators.

[kLabz]

@Simn it seems to be handled there: https://github.com/HaxeFoundation/haxe/blob/development/src/codegen/gencommon/hardNullableSynf.ml#L173

I get some results with a simple test, but break many things because it's just a naive one. I get:

testNadakoOps: FAILURE ....................F.....F...F.F.................F.....F...F.F...

instead of:

testNadakoOps: FAILURE .............F.F.F.FFF....FF..FFFF.........F.F.F.FFF....FF..FFFF..

[Simn]

For these cases we have to generate nullable == null ? false : unwrap(nullable) op otherValue

If both operands are nullable it has to be lhs == null ? rhs == null : rhs == null ? false : unwrap(lhs) op unwrap(rhs).

There might also be evaluation order concerns if the rhs is the nullable one...

[Simn]

I had a look like this but gencommon is too much for me to handle in this heat. Will maybe look at it again later...

[RealyUniqueName]

Maybe we should just unspecify >=, <=, < and > with null values.
Because our dynamic targets do this:

class Main {
	static var i:Int = null; // or `Null<Int>` no difference for dynamic targets

	public static function main():Void {
		i = null;
		trace(i == 0);
		trace(i < 0);
		trace(i > 0);
		trace(i >= 0);
		trace(i <= 0);
	}
}

python throws TypeError: '<' not supported between instances of 'NoneType' and 'int'
lua throws attempt to compare nil with number
php,js:

src/Main.hx:5: false
src/Main.hx:6: false
src/Main.hx:7: false
src/Main.hx:8: true
src/Main.hx:9: true

But if I comment out i = null; line in "main" function, then js emits this:

src/Main.hx:5: false
src/Main.hx:6: false
src/Main.hx:7: false
src/Main.hx:8: false
src/Main.hx:9: false

Also null safety emits a compile time errors for <,<=,>,=> ops with nullable values.

[ncannasse]

I think we should keep the spec defined by the provided unit tests for comparisons - for static targets at least - since they will match most dynamic targets specification (js in particular).

[Simn]

I think we should keep the spec defined by the provided unit tests for comparisons - for static targets at least - since they will match most dynamic targets specification (js in particular).

I have some trouble parsing what you mean here exactly. So, what do you mean here exactly?

[Simn]

In 2024, HL still fails many of the comparison tests against null. The problem seems to come from the fact that any null in x > null is converted to 0, which I don't think is correct. I think this kind of conversion should only be done when assigning to a basic type storage.

[Simn]

Fixed by #11612