Haxe version: latest (reproduced on 4.x)
Target: HashLink (hl)
Description
When using @:hlNative on an extern function inside a regular class, the compiler does not emit native function entries into the .hl bytecode. As a result, HashLink cannot resolve the functions at runtime and either crashes with JIT ERROR -1 or Failed to load function.
The same binding works correctly when the function has a stub body ({ return null; }) without the extern keyword.
Reproduction
Working:
class SysNative {
@:hlNative("std", "sys_locale")
static public function sysLocale(): hl.Bytes { return null; }
}Not working (no compile-time error, runtime crash):
class SysNative {
@:hlNative("std", "sys_locale")
static extern public function sysLocale(): hl.Bytes;
}Investigation
Comparing the two compiled .hl files shows that in the extern function variant, the native function name (sys_locale) is completely absent from the bytecode string table. The native entry is never written, so functions_indexes for that findex remains 0xFFFFFFFF, which triggers ASSERT(fid) in jit.c:1585 (op_call_fun).
Attempting to compile with --hl out.c also throws Invalid_argument("index out of bounds") for the extern variant, further confirming the issue is in the compiler emit phase.
Expected behavior
@:hlNative on an extern function should produce the same bytecode output as on a regular function with a stub body, consistent with how the feature works on other targets.
Haxe version: latest (reproduced on 4.x)
Target: HashLink (hl)
Description
When using
@:hlNativeon anexternfunction inside a regular class, the compiler does not emit native function entries into the.hlbytecode. As a result, HashLink cannot resolve the functions at runtime and either crashes withJIT ERROR -1orFailed to load function.The same binding works correctly when the function has a stub body (
{ return null; }) without theexternkeyword.Reproduction
Working:
Not working (no compile-time error, runtime crash):
Investigation
Comparing the two compiled
.hlfiles shows that in theexternfunction variant, the native function name (sys_locale) is completely absent from the bytecode string table. The native entry is never written, sofunctions_indexesfor that findex remains0xFFFFFFFF, which triggersASSERT(fid)injit.c:1585(op_call_fun).Attempting to compile with
--hl out.calso throwsInvalid_argument("index out of bounds")for the extern variant, further confirming the issue is in the compiler emit phase.Expected behavior
@:hlNativeon anexternfunction should produce the same bytecode output as on a regular function with a stub body, consistent with how the feature works on other targets.