[Tutez64]

When the loader refuses a batch, retryWithoutJit loads it again with the JIT off, in case the JIT is what it objects to. When that retry is refused as well, the JIT is not the cause, yet it stayed off (jit = false) for the rest of the process. It is now turned back on, and Compiler.jit stays true.

Odd: static var v:Int = LoadFailureTest.armed ? throw "boot" : 1;   // armed after the world starts
Fine: plain

before: Odd refused, Fine compiled, Compiler.jit == false
after:  Odd refused, Fine compiled, Compiler.jit == true

Tests

• LoadFailureTest.bootThrow. A refusal that survives the retry needs a module the loader refuses with and without the JIT: here a static initialiser that throws only when the compiled module boots, the flag being set after env.start() so the interpreted run passes. Without the fix, the JIT is still on fails.
• test/run.sh eval cpp: 421 / 421 / 454 passed (upstream: 421 / 421 / 451). Conformance columns (eval-interp, hxcpp-interp, hxcpp-cppia, hxcpp-cppia-jit) and the frontier are unchanged.
• Flixel sandbox (flixel 6.2.0, flixel-addons 4.0.1, flixel-ui 2.6.5), its four projects probed with the JIT on and off: same modules compiled, same byte counts, same two left interpreted (Playground, Shapes) as upstream. HashLink not run.