Repository navigation
Conversation
With HXCPP_GC_GENERATIONAL, Haxe treats a cpp.Function field as an object and emits HX_OBJ_WB(this,_hx_v.mPtr) in its setter, but cpp::Function has no mPtr, so any class with such a field fails to compile. HaxeFoundation/haxe#13002 stops emitting the barrier; until every compiler in use has it, a static null mPtr makes the barrier a no-op, which is right since a function pointer is not a GC object. test/haxe, built with HXCPP_GC_GENERATIONAL, now has a cpp.Function field and calls through it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
dimensionscape
added a commit
to openfl/libhxcpp
that referenced
this pull request
Oct 16, 2026
With HXCPP_GC_GENERATIONAL, Haxe 4.3.7 writes a barrier on _hx_v.mPtr in the setter of every cpp.Function field, and cpp::Function had no mPtr, so any class with such a field failed to compile. A static null mPtr under HXCPP_GC_GENERATIONAL makes the barrier compile and do nothing; HX_OBJ_WB skips a null value, and a function pointer is not a GC object. HaxeFoundation/haxe#13002 stops the generator emitting the barrier, for compilers that have it. From HaxeFoundation/hxcpp#1425 by Tutez64. Fixes #167 Co-authored-by: Enzo Persillet (Tutez) <enzopersillet@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
With
HXCPP_GC_GENERATIONAL, Haxe treats acpp.Functionfield as an object and emits a write barrier on_hx_v.mPtrin its setter:cpp::Functionhas nomPtr, so any class with such a field fails to compile:HaxeFoundation/haxe#13002 fixes the generator (HaxeFoundation/haxe#13001), but only for future compilers. This gives
cpp::Functiona static nullmPtrunderHXCPP_GC_GENERATIONAL, so the barrier that current compilers emit compiles and does nothing, which is right since a function pointer is not a GC object.test/haxe, which already builds withHXCPP_GC_GENERATIONAL, now has acpp.Functionfield and calls through it. With Haxe 4.3.7 it fails to compile without the change, and passes with it.