[r0ny123]

ARM mnemonic groups now receive the instruction operands. Float-suffixed NEON instructions using q registers classify as vector (V), while scalar VFP instructions stay float (F). Function/block recovery and PIC/opcode hashes are unchanged.

The compatibility marker is bumped to the current package version, 5.0.1, as required by the package-version invariant. Stored ARM escaped-block signatures need recomputing, including those from reports already labelled 5.0.1; the version field alone cannot distinguish those reports. The fingerprint corpus now includes both NEON and scalar VFP cases and checks the compatibility boundary.

Validation: 50 focused ARM/fingerprint tests passed; make lint, ruff format --check, and make typecheck passed. The combined pending-fix tree also passed the complete test suite (2,678 passed, one external-report-dependent test skipped).

[r0ny123]

Added ARM NEON and scalar VFP cases to the escaped-representation fingerprint and advanced the compatibility marker to the current package version, 5.0.1. Affected ARM escaped-block signatures need explicit recomputation, including reports already labelled 5.0.1; recovery and PIC/opcode hashes are unchanged.

Validation on 96b13bd: 61 ARM, fingerprint and package-metadata tests passed, along with the pinned hooks. CI, fuzzing, fixture benchmark, security and changelog workflows are green.

[danielplohmann]

The code change looks right to me, but the marker value needs to move:

ESCAPER_DOWNWARD_COMPATIBILITY = "5.0.1" names the release that is already out, so it cannot select the reports it is meant to invalidate. MCRIT only treats a sample as stale on a strict < (MongoDbStorage.recalculateAllPicHashes, and the threshold Worker.repairMinHashes hands to getSamplesWithStaleMinHashes), and 5.0.1 < 5.0.1 is false. So every ARM report produced by the released 5.0.1, with the old NEON grouping, passes as current. The CHANGELOG entry already says these need recomputing ("including reports already labelled 5.0.1"), but nothing downstream can find them.

Same pattern as 4.4.5: the marker should name the release that ships the output change. Please set it to the next version (5.0.2, or 5.1.0 if that is what goes out next) and bump __version__ with it at release, then drop the "already labelled 5.0.1" caveat from the entry. test_arm_group_change_has_a_compatibility_marker can then assert against that version.

[r0ny123]

Agreed, the marker has to name the release that ships the change. Pushed 0de9797:

• ESCAPER_DOWNWARD_COMPATIBILITY is 5.0.2, and the "already labelled 5.0.1" caveat is gone from the entry. __version__ stays at 5.0.1 for the release.
• test_arm_group_change_has_a_compatibility_marker asserts >= (5, 0, 2).
• test_the_escaper_compatibility_marker_is_not_newer_than_the_package would fail while the marker leads the package, so it is now ..._is_at_most_the_next_release: the marker may be at or below the package version, or exactly its next patch, minor or major release. The fingerprint test's docstring and failure message now say "the next release" instead of "the current package version".
• The CHANGELOG has a Compatibility line for the move from 4.4.5 to 5.0.2, as the header asks.

If 5.1.0 is what goes out next, it is a one-line change to the marker and the test.

[danielplohmann]

Thanks, the marker fix in 0de9797 is exactly right. #424 is merged now, so this is the last one in the batch: could you merge master in once more for the CHANGELOG? I'll merge it as soon as CI is green.