gh-157468: Validate correct builtins used under JIT

[johng]

This adds the two checks at tracing and at JIT runtime that the builtin dict is the original interpreter's builtins

• Issue: Tier 2 optimizer may use canonical builtins for functions with a copied __builtins__ dictionary #157468

[cocolato]

Please don't force push PRs. We‘ll squash merge commits at the end. And some comments:

[cocolato]

Thanks for doing this, there are also a few comments

[cocolato]

LGTM, and let's wait a core dev to review this

[markshannon]

We should be able to remove repeated checks in much the same way as do with ctx->frame->globals_checked_version by adding a ctx->frame->builtins_checked flag.

[markshannon]

We always allow enough headroom for small changes like this. No need to check here.

[markshannon]

Why are you adding the same instruction twice?
My mistake. convert_global_to_const converts the input inplace and relies on its being copied. We should probably update its interface, but that's for a different PR.

[cocolato]

The two ADD_OP calls emit different instructions:

// Rewrite this_instr as a constant load; nothing is emitted yet.
cnst = convert_global_to_const(this_instr, builtins);

if (cnst != NULL) {
    // Emit the builtins identity guard.
    ADD_OP(_GUARD_BUILTINS_IS_CANONICAL, 0, 0);

    // Emit the constant load prepared above.
    ADD_OP(this_instr->opcode, 0, this_instr->operand0);
}

[johng]

I reverted the last commit against my fork and the same test failed so don't think it's related (and didn't seem to be anyway)

1 test failed:
test.test_gdb.test_jit

Edit: Saying that main appears to be in a good state although confused about the failure here

[johng]

The failing test is now passing after latest merge to main @cocolato @markshannon I did some analysis and looks to be related to the code layout generated and whether a veneer is generated. I raised a separate issue above tracking it.

[methane]

Isn't keys->dk_version = 0; needed in clone_combined_dict_keys()? @markshannon