[cppia] haxe 4.3.7 version Unable to compile correctly using the hscript library

[rainyt]

Showing All Messages
 - src/haxe/ds/GenericStack_hscript_Token.cpp 

  141 |          ::Dynamic next(  ) {

      |          ~~~~~~~~~ ^

virtual function 'next' has a different return type ('::Dynamic') than the function it overrides (which has return type '::hscript::Token' (aka 'ObjectPtr<Token_obj>'))

   57 |                 virtual  ::hscript::Token next();

      |                          ~~~~~~~~~~~~~~~~ ^

Env:
haxe 4.3.7+189b8b0
hscript 2.6.0

Error:
Unable to compile through C++, resulting in the above error.

cppia_compile_error_hscript.zip

Only hscript.

[rainyt]

@Aidan63 Hi, Perhaps you are aware of this, as it was a problem that occurred after fixing it.
#11773

[tobil4sk]

I am able to reproduce it with:

// Main.hx
var a = new haxe.ds.GenericStack<Int>();

# build.hxml
-D scriptable
-cpp bin
Main

It looks like this issue was fixed in development with this patch: f56c0d4

[rainyt]

I am able to reproduce it with:

// Main.hx
var a = new haxe.ds.GenericStack();

build.hxml

-D scriptable
-cpp bin
Main
It looks like this issue was fixed in development with this patch: f56c0d4

Thank you, for this, if there is a new night build version, I am willing to test it!

[tobil4sk]

Any recent nightly build from development will include that patch.

Since this is a regression introduced by #11773, 4.3.7 should also include a backport of the fix for this issue too.

[rainyt]

@kLabz The branch in 4.3.7 still lacks this patch. Can a patch be added?

[rainyt]

I have observed that the cpp construction structure for the development version fix is different from 4.3.7, and it seems that it is not possible to directly synchronize the fix to version 4.3.7.

But if there is any news, I will continue to test hard, thank you.

[kLabz]

It is included in 4.3.7 #12044

[rainyt]

It is included in 4.3.7 #12044

This is not included: f56c0d4

Tobil4sk mentioned that this can fix such issues, so it may be necessary to include it?

@kLabz

[kLabz]

Oh, I thought this was about 11773, not that commit.. will add it (likely on Monday, I'm off for the rest of the week)

[rainyt]

Oh, I thought this was about 11773, not that commit.. will add it (likely on Monday, I'm off for the rest of the week)

Ok, Thanks, When you have time to merge, I will continue testing as well.

[Aidan63]

Unfortunately cherry picking that commit won't really work, it's part of the gencpp restructure thats happened in nightlies and I don't think we want to pull all of that into a patch release.
I'm also not sure it was something I explicitly went out of my way to fix, think it might just have been a "happy little accident" as part of the refactor. I can see how simple it would be to pack port the solution to the 4.3.x gencpp though.

[Aidan63]

Is there an exact sample which re-produces this issue?

function main() {
	final a = new GenericStack<Int>();
}

function main() {
	final a = new GenericStack<hscript.Parser.Token>();
}

Both of those compile fine on 4.3.6 when compiled with haxe -p src -m Main --cpp bin -D scriptable -L hscript.

[rainyt]

Is there an exact sample which re-produces this issue?

function main() {
final a = new GenericStack();
}

function main() {
final a = new GenericStack<hscript.Parser.Token>();
}
Both of those compile fine on 4.3.6 when compiled with haxe -p src -m Main --cpp bin -D scriptable -L hscript.

You need to use the pre release version 4.3.7: https://github.com/HaxeFoundation/haxe/actions/runs/13893699126

4.3.6 does not have this issue, it only occurs on branch 4.3.7.

[tobil4sk]

Both of those compile fine on 4.3.6

This only reproduces in versions that include #11773, e.g. in the 4.3.7 preparation branch

[Aidan63]

Right, I assumed that change was already in a 4.3.x release. Anyway, here's a patch based on the 4.3.7 prep branch which seems to fix the issue. Don't ask me how it works, because I don't know.

My thought process was to smash the original current_virtual_functions_rev code and the changes from #11773 together and see what happens. Turns out what happens is something which seems to fix the original inheritance issue and doesn't have the regression caused by the original fix attempt.

gencpp.patch