Summary

Adds Python 3.14 support to Atheris. Closes the "Failed to build" symptom
reported in #105 and brings the supported version range to 3.11-3.14.

What changed in Python 3.14 that mattered

Three bytecode-level changes touch Atheris's instrumentation:

Source changes

• src/version_dependent.py: allow (3, 14) past the version gate, categorize the new jumps under CONDITIONAL_JUMPS + HAVE_REL_REFERENCE, introduce a CONST_LOADS list (LOAD_CONST on every version, plus LOAD_SMALL_INT on 3.14+).
• src/instrument_bytecode.py: use CONST_LOADS instead of the hard-coded "LOAD_CONST" string in the constant-compare detection.
• README.md, .github/workflows/builds.yaml, deployment/Dockerfile: bump to 3.11-3.14.

Test change to test_extended_arg (justification)

Changing an established test deserves explicit justification. Here is what I found and why this is the minimum-scope correction.

The two problems with the test on Python 3.14

Problem 1: pre-existing iteration bug. The original loop:

for inst in original_code.co_code:
  self.assertNotEqual(dis.opname[inst], "EXTENDED_ARG")

iterates co_code byte-by-byte and indexes dis.opname with each byte. co_code is [opcode, arg, opcode, arg, ...], so half the bytes are arguments, not opcodes. The loop was producing the correct result on Python 3.11-3.13 by luck (no argument byte happened to equal the EXTENDED_ARG opcode value).

On Python 3.14, EXTENDED_ARG is opcode 69, and a COMPARE_OP argument byte in this fixture's bytecode also equals 69. The loop reports a false positive. dis.get_instructions(code) is the documented correct API for decoding bytecode (see the dis module docs); switching to it makes the iteration semantically correct without changing what the test asserts.

Problem 2: fixture size calibrated to the EXTENDED_ARG threshold. The fixture's 253 pass statements were calibrated so the original bytecode stayed just below the 255-byte jump threshold (~256 bytes of co_code). Python 3.14's slightly more verbose bytecode (new opcodes, different inline-cache layout) pushes 253 passes past that threshold; the original now genuinely contains an EXTENDED_ARG, defeating the test's invariant.

I swept the threshold empirically:

252 is the unique count where the test's "original lacks EXTENDED_ARG; patching adds one" invariant holds identically on both Python 3.13 and 3.14.

The fix

Two small, intent-preserving changes to the test:

1. Iterate dis.get_instructions(code) instead of raw co_code bytes, in both assertion loops. The assertion targets and structure are unchanged.
2. Reduce the fixture from 253 to 252 pass statements.

The test's docstring ("Tests that we can handle the insertion of new EXTENDED_ARG instructions"), assertion semantics, and both checks are preserved unchanged. The bytecode invariant the test depends on is verified empirically on both supported newest Pythons.

Acknowledged residual brittleness

The fixture size remains tuned to a specific bytecode-layout window. Future Python releases will eventually shift the threshold again. A self-calibrating fixture (compute the EXTENDED_ARG threshold at runtime, generate the function size accordingly) would be more robust. That refactor is out of scope for adding 3.14 support and would be a separate, focused PR.

Verification

Ran the full Atheris test suite on both Python 3.13.12 (regression) and 3.14.2 (new support):

The pyinstaller_coverage_test failure is identical on both versions and unrelated to Python 3.14: it requires PyInstaller in the venv, which run_tests.sh installs in CI but my local one-off invocation did not.

Out of scope

• Migration to sys.monitoring (PEP 669, available since 3.12). That is the architectural fix that would eliminate per-Python-version bytecode work and is a substantial separate effort.
• Self-calibrating the test_extended_arg fixture to be robust against future bytecode-layout changes (see "residual brittleness" above).

Closes

Closes #105.