Skip to content

autosetup: instantiate $ templates against the contract's real methods - #106

Merged
jar-ben merged 6 commits into
masterfrom
jaroslav/autosetup-extload-method-aware-instantiation
Jul 27, 2026
Merged

autosetup: instantiate $ templates against the contract's real methods#106
jar-ben merged 6 commits into
masterfrom
jaroslav/autosetup-extload-method-aware-instantiation

Conversation

@jar-ben

@jar-ben jar-ben commented Jul 24, 2026

Copy link
Copy Markdown
Contributor

process_template_in_place blindly substituted $CONTRACT_NAME$ and emitted every entry a template declares. The extload template lists extsload/exttload/extSload overloads and return variants that come from different mixins (Uniswap Extsload/Exttload, Aave ExtSload), so any given contract implements only a subset. Emitting the rest produced two hard CVL typecheck failures:

  • combineFunctions "un-mergeable signature …" — the template has two entries for the same signature with different returns (extsload(bytes32,uint256)→bytes32[] and →bytes; same for exttload(bytes32[])), which CVL can't merge.
  • "Only public/external methods are DELETE-able" — a DELETE summary emitted for a method the contract doesn't have.

Fix

_filter_template_entries_to_contract keeps only the materialized methods{} entries matching a real method of the contract — by (name, parameter types, return type) — using methods_parser.get_methods_by_originating_contract. Consequences:

  • same-signature/different-return duplicates collapse to the single variant the contract has (so both →bytes32[] and →bytes projects stay supported — the per-contract instantiation resolves it);
  • entries for absent methods are dropped;
  • non-matching receivers (wildcard _.) and all non-entry lines (CVL helper functions, comments) are preserved verbatim;
  • if the contract's methods can't be determined, content is returned unchanged (no accidental over-pruning).

Why not just delete the →bytes variants / separate templates

The →bytes variants are original (pre-existing) and intended for real projects, so deleting them loses coverage. Separate templates don't help — the registry matches by name, so both would still apply. The discriminator is the return type, which only the contract's actual method carries; hence method-aware instantiation.

Validation

  • tests/test_extload_template_filter.py (new, 4 cases): keep-only-matching, no-duplicate-signatures, keeps-bytes-variant-when-that's-what-the-contract-has (the two-return case), and unknown-methods-leaves-content-unchanged. Full summary unit suite green (23 passed).

Dependencies & follow-ups

  • Stacked on PRs 1–4. Fixes a pre-existing template-instantiation flaw that PR 2 (adding extSload matching) exposed

@jar-ben
jar-ben requested a review from naftali-g July 26, 2026 06:05
Base automatically changed from jaroslav/autosetup-fix-optimize-map-reconciliation to master July 27, 2026 09:58
@jar-ben
jar-ben merged commit ccc20c7 into master Jul 27, 2026
2 checks passed
@jar-ben
jar-ben deleted the jaroslav/autosetup-extload-method-aware-instantiation branch July 27, 2026 10:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants