Step 7 of the lint job, scripts/addr_class_inventory.py, exits 1 on main (cdb3934). It is currently masked: the job stops at step 3 (#7257), so this has not been visible in CI.
Confirmed unrelated to #7256 (the file-size split) — that PR's finding set is byte-identical to main's.
There are two independent problems.
1. Two genuine ratchet regressions
[handle-floor] crates/perry-runtime/src/child_process/value_util.rs: 3 site(s), baseline allows 1
line 103: if ptr.is_null() || (ptr as usize) < 0x1000 {
line 222: if opts_ptr > 0x10000 {
line 225: if args_ptr <= 0x10000 {
[handle-floor] crates/perry-runtime/src/fs/dirent.rs: 3 site(s), baseline allows 2
line 132: if raw_ptr < 0x1000 {
line 184: if raw_ptr < 0x1000 {
line 217: if refreshed_ptr < 0x1000 {
Three new hand-rolled address floors landed without going through
crates/perry-runtime/src/value/addr_class.rs. Per the gate's own rationale these should use is_handle_band / is_above_handle_band / try_read_gc_header: a bare < 0x1000 floor does not reject the fetch/zlib/proxy handle bands, and dereferencing a handle segfaults on Linux while macOS hides it (#1843, #4004, #4665, #4800, #6271).
This is a real correctness fix, not bookkeeping — it should not be silently ratcheted up.
2. A stale allowlist entry that no longer matches its code
crates/perry-runtime/src/object/native_module/constants.rs: [band-literal] ("O_SYMLINK", (0x200000) as f64),
scripts/addr_class_allowlist.txt has an entry keyed on both a path prefix and a line substring:
crates/perry-runtime/src/object/native_module/constants.rs | "O_SYMLINK" => Some(0x200000), | fs.constants O_SYMLINK flag value; unrelated to the handle bands (split of native_module.rs)
constants.rs contains O_SYMLINK in two syntaxes, and the entry only matches one of them:
"O_SYMLINK" => Some(0x200000), — matches, suppressed
("O_SYMLINK", (0x200000) as f64), — does not match, so it fails the gate
Both are the POSIX O_SYMLINK fcntl flag value, unrelated to the handle bands. The fix is a second allowlist entry (or widening the substring to O_SYMLINK).
Related: pre-existing baseline staleness (warning-only)
check_ratchet also reports stale entries — counts that dropped without the baseline being lowered. These do not fail the run (they are printed after the return 1), but they are drift:
handle-floor | crates/perry-runtime/src/node_submodules/test.rs: baseline 2, actual 1
handle-floor | crates/perry-runtime/src/process/env_misc.rs: baseline 3, actual 1
Two whole-file allowlist entries also appear to suppress nothing any more and could be dropped (verified by running the inventory with and without them and diffing the output):
crates/perry-runtime/src/array/generic.rs | *
crates/perry-runtime/src/node_submodules/test.rs | *
Design note worth considering
Both the ratchet baseline and the whole-file allowlist entries are path-keyed. That makes any file split a potential gate failure even when no code changed: a ratcheted site moving to a new sibling gets baseline 0 (hard fail), and allowlisted code moving out of an allowlisted path loses its suppression. #7256 hit both and had to re-pick seams to keep specific functions in their original files. If file splits are expected to continue (#1435), it may be worth keying suppressions on something more stable than the path.
Step 7 of the
lintjob,scripts/addr_class_inventory.py, exits 1 onmain(cdb3934). It is currently masked: the job stops at step 3 (#7257), so this has not been visible in CI.Confirmed unrelated to #7256 (the file-size split) — that PR's finding set is byte-identical to
main's.There are two independent problems.
1. Two genuine ratchet regressions
Three new hand-rolled address floors landed without going through
crates/perry-runtime/src/value/addr_class.rs. Per the gate's own rationale these should useis_handle_band/is_above_handle_band/try_read_gc_header: a bare< 0x1000floor does not reject the fetch/zlib/proxy handle bands, and dereferencing a handle segfaults on Linux while macOS hides it (#1843, #4004, #4665, #4800, #6271).This is a real correctness fix, not bookkeeping — it should not be silently ratcheted up.
2. A stale allowlist entry that no longer matches its code
scripts/addr_class_allowlist.txthas an entry keyed on both a path prefix and a line substring:constants.rscontains O_SYMLINK in two syntaxes, and the entry only matches one of them:"O_SYMLINK" => Some(0x200000),— matches, suppressed("O_SYMLINK", (0x200000) as f64),— does not match, so it fails the gateBoth are the POSIX
O_SYMLINKfcntl flag value, unrelated to the handle bands. The fix is a second allowlist entry (or widening the substring toO_SYMLINK).Related: pre-existing baseline staleness (warning-only)
check_ratchetalso reports stale entries — counts that dropped without the baseline being lowered. These do not fail the run (they are printed after thereturn 1), but they are drift:handle-floor | crates/perry-runtime/src/node_submodules/test.rs: baseline 2, actual 1handle-floor | crates/perry-runtime/src/process/env_misc.rs: baseline 3, actual 1Two whole-file allowlist entries also appear to suppress nothing any more and could be dropped (verified by running the inventory with and without them and diffing the output):
crates/perry-runtime/src/array/generic.rs | *crates/perry-runtime/src/node_submodules/test.rs | *Design note worth considering
Both the ratchet baseline and the whole-file allowlist entries are path-keyed. That makes any file split a potential gate failure even when no code changed: a ratcheted site moving to a new sibling gets baseline 0 (hard fail), and allowlisted code moving out of an allowlisted path loses its suppression. #7256 hit both and had to re-pick seams to keep specific functions in their original files. If file splits are expected to continue (#1435), it may be worth keying suppressions on something more stable than the path.