test(fact): LS-A-8 regression for inner-list rep_func selection#169
Open
avrabe wants to merge 1 commit into
Open
test(fact): LS-A-8 regression for inner-list rep_func selection#169avrabe wants to merge 1 commit into
avrabe wants to merge 1 commit into
Conversation
Final missing-bucket entry. Drives the LS-N verification gate to
19/19 verified — full coverage.
For a `list<record { x: borrow<A>, y: borrow<B> }>` (or any list
whose elements carry borrows to multiple distinct resource types),
`analyze_call_site` walks the inner-resources slot and emits a
fixup per slot mapping its byte_offset to the merged-module index
of the right `[resource-rep]` import.
The pre-fix code did `resource_rep_imports.values().next()` —
HashMap iteration order, so the rep_func picked for each slot was
effectively random. Borrow handles of resource A then routed
through resource B's rep_func and vice versa, producing silent
rep-vs-handle confusion across the cross-component handle
boundary (H-4 / H-4.2, UCA-A-7). Wasm validator accepts (both
`[resource-rep]X` and `[resource-rep]Y` are `(i32) -> i32`); the
divergence only surfaces when downstream runtimes execute the
fused module against typed callers.
Two tests:
- `ls_a_8_inner_list_rep_func_selected_by_type_not_iteration_order`
Adversarial fixture with two InnerResources at distinct
byte_offsets, each pointing at a different rep_import key.
Sampled 32× across rebuilt HashMaps (so each sample sees a
fresh hash seed). If any residual iteration-order dependence
leaked, at least one sample would pair wrongly; the assertion
pins the per-type lookup as deterministic.
- `ls_a_8_no_rep_import_skips_fixup_rather_than_picking_arbitrary`
InnerResource.rep_import = None — the resolver couldn't map the
type id to an import. Pre-fix `.values().next()` would fall back
to whatever entry the HashMap iterated first, emitting a fixup
pointing at the WRONG rep_func. The post-fix path correctly
skips the slot (with a `log::warn`) rather than fabricating an
arbitrary mapping.
Gate verdict: 18/19 → 19/19 verified. The advisory missing-bucket
is now empty.
237/237 → 239/239 in `meld-core --lib`.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Mythos delta-pass requiredThis PR modifies one or more Tier-5 source files (per Before merge, run the Mythos discover protocol on the
Why this gate exists: LS-A-10 The gate check on this PR will pass once the label is |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The final missing-bucket entry. Drives the LS-N verification gate to 19/19 verified — full coverage.
PR f0e981b fixed the
resource_rep_imports.values().next()HashMap-iteration-order bug inanalyze_call_site(inner-list borrow rep_func selection) by threading a pre-resolvedrep_import: Option<(String, String)>throughInnerResourceand looking up per-type. The fix landed without a regression test; the LS-N verification gate has been flagging this since #161.Why this matters
For
list<record { x: borrow<A>, y: borrow<B> }>, the pre-fix code picked the same arbitrary rep_func for both A and B handles. Borrow handles of resource A then routed through resource B's rep_func (silent rep-vs-handle confusion across cross-component handle boundary, H-4 / H-4.2, UCA-A-7). Wasm validator accepts (both[resource-rep]Xand[resource-rep]Yare(i32) -> i32); divergence only surfaces at downstream runtime execution.Test approach
ls_a_8_inner_list_rep_func_selected_by_type_not_iteration_orderls_a_8_no_rep_import_skips_fixup_rather_than_picking_arbitrary.values().next()fall-back-on-miss would fabricate a fixup pointing at an arbitrary rep_func when the resolver couldn't map the type id. The post-fix path correctly skips withlog::warn. This test pins that skip-not-fabricate behaviour.Gate verdict
Advisory missing-bucket is now empty. Every
status: approvedLS entry has a passing regression test.Local test run
Full lib: 237/237 → 239/239.
End-to-end mythos-auto status
This PR touches
meld-core/src/adapter/fact.rs(Tier-5) so the auto-runner fires. Sameunzip-missing infra block as PR #166 expected (#167). LS-A-9 test itself was admin-merged via #166; same path likely needed here.🤖 Generated with Claude Code