Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reflect.compareMethods doesn't work as expected #578

Open
TC218 opened this issue Jan 21, 2023 · 2 comments
Open

Reflect.compareMethods doesn't work as expected #578

TC218 opened this issue Jan 21, 2023 · 2 comments

Comments

@TC218
Copy link

TC218 commented Jan 21, 2023

using https://github.com/haxe-utest/utest
$ haxe hxml/common.hxml -hl bin/test.hl
$ hl bin/test.hl

shows errors in file
https://github.com/haxe-utest/utest/blob/master/test/utest/TestDispatcher.hx#L9-L18
it uses class from src/utest/Dispatcher.hx where error happens in function remove():
https://github.com/haxe-utest/utest/blob/master/src/utest/Dispatcher.hx#L59-L66

@ncannasse
Copy link
Member

The problem is actually quite complex to solve. It can be reproduced using this minimal sample:

class Main {

	static var LAST = null;
	static function foo<T>( x : T -> Void ) { LAST = x; return x; }
	static function test<T>( x : T -> Void ) return Reflect.compareMethods(x,LAST);

	static function main() {
		var h = foo(function(x : String) {});
		Sys.println(test(h)); // false should be true !
	}

}

What happens is that passing function(x:String){} to a T->Void generates a wrapper closure:

		.9     @0 staticclosure 1, fun$31
		.9     @1 jnotnull 1,2
		.9     @2 null 0
		.9     @3 jalways 1
		.9     @4 instanceclosure 0, fun$32(1)
		.9     @5 call 0, Main.foo(0)

And when calling "test", we wrap again the wrapped closure because we can't tell at compilation it's been already wrapped:

		.10    @9 instanceclosure 0, fun$32(0)
		.10    @A call 3, Main.test(0)

So the two methods ends up being closures over a different subfunction.

Solving this would require to be able to identify a wrapper generated closure from an user one and unwrap it in fun_compare

@T1mL3arn
Copy link

T1mL3arn commented Jan 8, 2024

Found similar problem with flixel dispatcher. As a temporary workaround for my case I just used Void->Void signals.

T1mL3arn added a commit to T1mL3arn/flixel that referenced this issue Jan 8, 2024
Geokureli pushed a commit to HaxeFlixel/flixel that referenced this issue Jan 8, 2024
* Remove handler directly since we already work with it. This fixes one-time listeners for HL target ( see HaxeFoundation/hashlink#578 )

* upd unit tests
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants