Test that Trio works around some CPython .throw bugs present in >= 3.9

[gschaffner]

the current tests that ensure Trio works around CPython .throw bugs are all for .throw bugs that were fixed in 3.9.0 or earlier. however .throw is still buggy in every CPython release supported by Trio today.

to test the new tests (i.e. to verify that they do indeed fail if Trio removes its CPython .throw workaround before Trio drops support for 3.12.0 (at least)), one can apply 256568e and run the test suite on CPython 3.9.x, 3.10.x, 3.11.x, 3.12.x, and/or 3.13-dev. when one does this, the two new tests fail (and they are the only tests that fail).

[codecov]

Codecov Report

Merging #2879 (6784759) into master (a15d0f9) will increase coverage by 0.00%.
The diff coverage is 100.00%.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #2879   +/-   ##
=======================================
  Coverage   99.54%   99.54%           
=======================================
  Files         115      115           
  Lines       17660    17700   +40     
  Branches     3165     3170    +5     
=======================================
+ Hits        17580    17620   +40     
  Misses         52       52           
  Partials       28       28           

Files	Coverage Δ
src/trio/_core/_run.py	100.00% <ø> (ø)
src/trio/_core/_tests/test_run.py	100.00% <100.00%> (ø)

[jakkdl]

I'm not able to comment on the actual logic or internals, but seems fine at a glance.

It would be great in theory to be able to automate applying the mentioned patch and xfail tests (something like env variables or monkeypatching some functions), but I'm not sure that's worth the effort and upkeep.

[jakkdl]

I'm slightly confused that the test doesn't have any calls to sys.version_info when it talks about differing behaviour on different python versions. Can maybe clarify the comment a bit more in that respect?

[gschaffner]

ah! the tests should not change their behavior based on sys.version_info because the behavior of .throw, and of Trio, is supposed to be the same for each different (supported) Python language version.

perhaps it is clearer with a concrete example: when CPython fixed the first of these .throw bugs in CPython 3.7.0, it was a bugfix to the CPython implementation, but it was not a change to the Python language. that is, the bugfix made in CPython 3.7.0 did not correspond to any change made in Python 3.7.0, because the language did not change; it was just a CPython-implementation bugfix¹.

in the comment

every CPython release is affected ([...]) (albeit in differing ways).

i meant to convey that .throw is buggy in all CPython releases and (in the parenthetical) that the ways in which it is buggy are different between the different CPython releases, ². it's because of exactly those differences that Trio's current CPython .throw tests are insufficient and need to be expanded from 2 cases to all 4 cases (or at least all 4 cases that i know about c: ).

Footnotes

1. for example, even though CPython3.6.z had this bug (in the sense that CPython3.6.z didn't correctly implement the Python3.6.z specification for the "active exception" in this particular situation until CPython 3.7.0), PyPy3.6.z still implemented it correctly. ↩

2. because the bugs have been found incrementally and are being fixed incrementally—some in 3.7.0, some in 3.9.0, and some in $FUTURE_CPYTHON_VERSION(S). ↩

[jakkdl]

Right. It's only if we applied that patch that we'd get different behaviour depending on python version. And the workaround implemented by trio, for this specific bug/test, is redundant on py3.9+, and when we drop support for 3.8 in oct 2024 we could remove this test and any corresponding workaround.

[gschaffner]

It would be great in theory to be able to automate applying the mentioned patch and xfail tests (something like env variables or monkeypatching some functions), but I'm not sure that's worth the effort and upkeep.

the nice thing is that Trio cannot change its internals in a way that would cause these tests to stop testing what they are supposed to be testing. now that they have been verified, the only way to make these tests stop working correctly is by directly modifying them. given that the original two tests here have not been modified since they were added in 2017 (excluding formatting/annotations), i think that's unlikely.

so i think that maintaining that _core.{_run,_traps} patch (plus tooling for testing these tests) until (at least) 3.12 support is dropped (>= 2028) is IMO not necessary or worth it. as long as everyone continues to be careful about not modifying weird low-level CPython bug workaround regression tests unless they're certain about what they're doing, there shouldn't be problems :)

[gschaffner]

rebased to resolve the conflicts with #2884