[hxb] Unbound type parameter issues

[kLabz]

Added failing tests with currently identified issues:

Local function type parameter vs @:generic

class Main {
	static function main() {
		function foo<T>(arr:Array<T>) sortDesc(arr);

		foo([""]);
		foo([42]);
	}

	@:generic
	public inline static function sortDesc<T>(array : Array<T>) {}
}

Warning : (WUnboundTypeParameter) Unbound type parameter foo.T

Not sure how that one should behave; if that's not supposed to be supported, it should at least error/warn properly. Note that this doesn't really break.

Anon field type parameter in abstract underlying type

typedef Foo = {
	function get<TField>():Null<TField>;
}

abstract HaxeMemento(Foo) {
	public function getInner<TAbstract>():Null<TAbstract> {
		return this.get();
	}
}

Here, first compilation is fine, second gives an unbound type parameter warning, and third crashes.
Crash avoided in 0e96fae

[kLabz]

I could dodge the crash by adding TPHUnbound that represents the "error state" so that next compilation doesn't hit a Dynamic that triggers the crash by not pulling the local context.

I'm not really fond of that patch, but it makes things a bit better for such cases.

As for the actual unbound type parameter warnings here (which still make the tests fail as they currently expect no output), I'm not sure what to do. They do seem like actual unbound type parameters, which would mean current result is fine? 🤔

[Simn]

Yes I don't think there's a hxb-specific problem here, it's likely all related to #3033.

[kLabz]

What about that TPHUnbound patch? Should I add it to development to avoid crashes?

[Simn]

Seems a bit strange but if it helps temporarily then I don't mind.

[kLabz]

#4599 (comment)

One solution for this might be to allow partial generic expansion. Basically, if we substitute a generic type parameter with a non-generic one, we absorb that type parameter into the new function and make the function @:generic again.

This would require reapplying calls to generic functions, but I think this is exactly the same situation as overload calls for which we already do that anyway.

Is that what we need for first case here?