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

[cs/java(not-jvm)] invalid closure generation with @:generic + structure typing #9395

Closed
nadako opened this issue May 7, 2020 · 3 comments · Fixed by #11376
Closed

[cs/java(not-jvm)] invalid closure generation with @:generic + structure typing #9395

nadako opened this issue May 7, 2020 · 3 comments · Fixed by #11376
Labels
bug platform-cs Everything related to c# platform-java Everything related to Java
Milestone

Comments

@nadako
Copy link
Member

nadako commented May 7, 2020

class Main {
	@:generic
	static function d<T:{function dispose():Void;}>(o:T):()->Void {
		return o.dispose;
	}

	function new() {}

	static function main() {
		var dispose = d(new Main());
		dispose();
	}

	public function dispose() {
		trace("Disposing");
	}
}

this generates the following C#:

public static global::haxe.lang.Function d_Main(global::Main o) {
	return ((global::haxe.lang.Function) (o.dispose) );
}

which then of course fails on native compilation, because o.dispose is indeed not a haxe.lang.Function


if we remove @:generic it will work via dynamic access:

public static global::haxe.lang.Function d<T>(T o) {
	return ((global::haxe.lang.Function) (global::haxe.lang.Runtime.getField(o, "dispose", 994869407, true)) );
}

but with @:generic it should generate the same code as if we'd have T:Main instead of a structure:

public static global::haxe.lang.Function d_Main(global::Main o) {
	return ((global::haxe.lang.Function) (new global::haxe.lang.Closure(o, "dispose", 994869407)) );
}
@nadako nadako added platform-java Everything related to Java platform-cs Everything related to c# bug labels May 7, 2020
@nadako
Copy link
Member Author

nadako commented May 7, 2020

This might be an issue with the AST (cc @Simn @RealyUniqueName) - note FClosure has None for a class.

@:noCompletion @:noUsing @:genericInstance
static function d_Main[Function:(o : Main) -> (Void -> Void)]
	[Arg:Main] [Local o(141964):Main]
	[Block:Dynamic]
		[Return:Dynamic]
			[Field:Void -> Void]
				[Local o(141964):Main:Main]
				[FClosure:Void -> Void]
					None
					dispose:Void -> Void

@RealyUniqueName
Copy link
Member

Looks like a typer issue in generic_substitute_expr

@RealyUniqueName RealyUniqueName added this to the Bugs milestone May 15, 2020
@Simn
Copy link
Member

Simn commented Feb 22, 2022

I'm not closing this one even though it's Java/C# specific, because the AST looks wrong here.

@Simn Simn modified the milestones: Bugs, Later Mar 24, 2023
Simn added a commit that referenced this issue Nov 15, 2023
@Simn Simn closed this as completed in 128261a Nov 15, 2023
0b1kn00b pushed a commit to 0b1kn00b/haxe that referenced this issue Jan 25, 2024
* change return of build_instance to record

* also rename

* also seperate

* also bring back typedef deprecation check

* alsp keep special cases in the right place

* mess around

* avoid some work if we need no params anyway

* make @:generic inference work again

* remove Generic_Exception

* push expected type before loading instance

closes HaxeFoundation#3864

* expand generic types on field call candidate when expanding generic function

closes HaxeFoundation#5482

* build generic parents as well

closes HaxeFoundation#6761

* inherit `@:autoBuild` to generic instance

closes HaxeFoundation#5536

* also inherit @:keepSub while we're at it

closes HaxeFoundation#6500

* deal with KExpr in generic classes properly

closes HaxeFoundation#7574

* don't inherit cf_expr_unoptimized to generic instances

closes HaxeFoundation#9358

* reroute FClosure in map_expr_type

closes HaxeFoundation#9395

* inherit cl_using to generic instances

closes HaxeFoundation#10528

* set inherited flags on generic instance fields at the right time

closes HaxeFoundation#11010

* I really don't care

* wild guess

* avoid the follow change
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug platform-cs Everything related to c# platform-java Everything related to Java
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants