gh-132732: Clear errors in JIT optimizer on error

[Fidget-Spinner]

• Issue: Constant evaluate/propagate pure ops automatically #132732

[tomasr8]

Asking just to educate myself: what kind of errors are we expecting inside the JIT and is it safe to always clear them?

[brandtbucher]

In general, we want to shift as much computation as possible to optimization-time instead of runtime. Some classes of errors, like MemoryError, are unavoidable. In these cases, we can just ignore them and trust that they'll either resolve themselves or surface in normal user code soon (it's a bit confusing if we raise an error like this in seemingly "random" places where JIT compilation may kick in).

The other class of errors are ones that are easier to ask forgiveness than permission for. For example, constant-evaluating stuff like a / b, a % b, a >> b, a << b, a[b], and so on, where a and b are known "safe" constants in the JIT. It's way easier to just try the operation and assume it will succeed, and just walk back any errors when it doesn't (in this latter case, the error will just happen at runtime when the operation is evaluated "for real").

[brandtbucher]

Shouldn't this be:

Suggested change

	if (PyErr_Occurred()) {
	PyErr_Clear();
	}
	assert(PyErr_Occurred());
	PyErr_Clear();

...or are there cases where an error hasn't occurred, but we end up here?

[Fidget-Spinner]

I think the current code goes to error on some cases where we run out of memory too, but no memoryerror is set.

[brandtbucher]

I don't think so, all uses of goto error in these files seem like they have an error set.

[Fidget-Spinner]

@tomasr8 may I trouble you with a review please?

[tomasr8]

Given Brandt's explanation, this looks good to me :) I just left one question/comment