The following test case debug asserts: Assertion failure: false (Delazification target is not ready. Bad XDR?), at unified/js/src/frontend/Stencil.cpp:758

// This source can almost certainly be reduced, it was developed while trying to find a
// bug.
var source = `
function f() {
    function g() {
        return 10;
    }
    return g();
}

f()`

var code = cacheEntry(source);

// Populate delazification indexes

var res = evaluate(code, { saveIncrementalBytecode: true, })
assertEq(res, 10)

// Instantiate delazification entries from stencil set, but set sourceIsLazy here
// this means that we don't run Phase 6 of stencil instantiation, and everything breaks.
// global.run = true;
res = evaluate(code, { loadBytecode: true, sourceIsLazy: true })
assertEq(res, 11)

Root cause is that here we use CompileOptions to decide if there ought to be lazy functions that need instantiation, but sourceIsLazy being changed between save and load confuses things.

We should continue to lock down consistency here. I think we want to have the nsFrameMessageManager use sourceIsLazy for consistency with the others. Using something like this probably makes sense. The finding before was that scriptpreloader is much more effective if all bytecode is there. The source-retrieval hook is compatible here too.

bug 1719402 moved the condition to CompilationStencil.canLazilyParse, and now the CompileOptions isn't used as the condition, but still checked during instantiation, and the inconsistency is reported as JS error.