Open kLabz opened 6 months ago
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? :thinking:
Yes I don't think there's a hxb-specific problem here, it's likely all related to #3033.
What about that TPHUnbound
patch? Should I add it to development to avoid crashes?
Seems a bit strange but if it helps temporarily then I don't mind.
https://github.com/HaxeFoundation/haxe/issues/4599#issuecomment-1641549931
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?
Added failing tests with currently identified issues:
Local function type parameter vs @:generic
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
Here, first compilation is fine, second gives an unbound type parameter warning, and third crashes. Crash avoided in 0e96faee8ebddbbf8d56ee340635d377f80cef59