gh-151112: Fix crash in compiler_mod() when entering the current compilation unit fails

[StanFromIreland]

_PyCodegen_EnterAnonymousScope can fail to enter the module's compilation unit (e.g. when OOM, like the in repro), so c->u is left NULL. compiler_mod's cleanup then calls _PyCompile_ExitScope, which derefs that NULL unit in compiler_unit_free and segfaults.

The reproducers start/stop for nomemory will probably have to be adjusted, but for me I can reproduce with:

import _testcapi

compile("pass", "<warmup>", "single")
_testcapi.set_nomemory(31, 32)
try:
    compile("pass", "<trigger>", "single")
except MemoryError:
    pass
first = bytes(128)
second = bytes(128)

Skipping news, the other PR has one which I think can cover this too, these are both quite rare.

• Issue: Double free corruption when allocation failures occur in assemble_init #151112

[iritkatriel]

Are we sure c->u was NULL when we entered compiler_mod? Can we assert that at the top of the function?

[StanFromIreland]

Yes, in _PyAST_Compile we initialise c:

cpython/Python/compile.c

Lines 1527 to 1532 in 9fd1a12

	compiler *c = new_compiler(mod, filename, pflags, optimize, arena, module);
	if (c == NULL) {
	return NULL;
	}
	PyCodeObject *co = compiler_mod(c, mod);

But new_compiler doesn't set c->u.

[miss-islington-app]

Thanks @StanFromIreland for the PR 🌮🎉.. I'm working now to backport this PR to: 3.13, 3.14, 3.15.
🐍🍒⛏🤖

[miss-islington-app]

Sorry, @StanFromIreland, I could not cleanly backport this to 3.13 due to a conflict.
Please backport using cherry_picker on command line.

cherry_picker 937d89c4d9b7c5fda6730a1127db118d881d13cb 3.13

[bedevere-app]

GH-151350 is a backport of this pull request to the 3.15 branch.

[bedevere-app]

GH-151351 is a backport of this pull request to the 3.14 branch.