Simon Krajewski
Simon Krajewski
I agree anything `inline` should not be reflective. These two concepts just don't mix.
I think "being reflective" is one level above "being generated". But that probably depends on the actual target.
What about `@:extern`? The semantics of that aren't really clear to me because we basically use it as `@:forceInline`.
I confirm this is still an issue on hxcpp.
That commit kinda looks like it shouldn't be a thing, but then that's probably mostly because this special `_std` handling shouldn't be a thing in the first place... so I...
``` haxe class Parent { public var x:Int; public inline function new(x:Int) { this.x = x; } } class Child extends Parent { } class Main { static function main()...
Sanity check: You don't want this to actually inline anything, right?
Actually I think we can safely inline `super()` calls while inlining. They could only appear within an inline constructor so their expression can be inlined there.
I came across this too, but it was apparently random on CI runs and I couldn't determine why it would happen.
It just happened again here: https://github.com/Aidan63/haxe/actions/runs/15322780344/job/43110496352?pr=99 ``` Test optimization: Changing directory to D:\a\haxe\haxe\tests/optimization/ Command: haxe [run.hxml] src/TestBaseMacro.hx:23: Done 123 tests (0 failures) src/TestBaseMacro.hx:23: Done 0 tests (0 failures) src/TestBaseMacro.hx:23: Done...