WIP: example class hash forward.

[orizi]

Summary

Adds a test and accompanying test data for static interface forwarding via the compile-time class-hash feature. A new static_forwarding_contract.cairo example demonstrates a static_proxy contract that forwards all ICounterContract calls as library calls to counter_contract's class using the compile-time-injected ForwardingClassHashImpl — requiring no stored class hash and no constructor. The new static_forwarding_compiles test verifies that the proxy compiles successfully and exposes exactly the two forwarded external entry points.

---

Type of change

Please check one:

• Bug fix (fixes incorrect behavior)
• New feature
• Performance improvement
• Documentation change with concrete technical impact
• Style, wording, formatting, or typo-only change

---

Why is this change needed?

The compile-time class-hash / forward-impl feature lacked test coverage for the static forwarding pattern. Without a test, regressions in the two-pass Sierra injection or the ForwardingClassHashImpl generation could go undetected.

---

What was the behavior or documentation before?

There was no test exercising static proxy forwarding using counter_contract::__class_hash__::ForwardingClassHashImpl. Only the dynamic proxy pattern (with a stored class hash and constructor) was covered.

---

What is the behavior or documentation after?

A static_forwarding_compiles test compiles the static_proxy contract and asserts that:

• Compilation succeeds (no panics or errors).
• Exactly two external entry points are exposed (matching the two methods of ICounterContract).
• The compiled contract passes sanity_check().

---

Related issue or discussion (if any)

N/A

---

Additional context

The static_proxy contract uses the #[feature("forward-impl")] attribute and delegates to counter_contract's class hash, which is injected by the two-pass compilation in compile_path. This is distinct from the existing class_hash_injection_compiles test, which only verifies deterministic recompilation of the injected hash, not the forwarding behavior itself.

[reviewable-StarkWare]

This change is 

[orizi]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• WIP: example class hash forward. #10163 👈 (View in Graphite)
• feature(starknet): Adding injected class-hash values into code. #10160
• feature(sierra-gen): Added support for injecting constant values externally. #10159
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[Arcticae]

ideally we'd like not to have to specify both of those - would that be possible?

[orizi]

you would ALWAYS have to state both - these are completely independent concepts.
you could (and mostly should) do it in a oneliner.

#[abi(embed_v0)]
impl ForwardedImpl =
     // The forwarded trait.
     super::ICounterContractForwardImpl<
         ContractState,
         // Where is it forwarded to.
         super::counter_contract::__class_hash__::ForwardingClassHashImpl<ContractState>,
    >;

[orizi]

@orizi made 1 comment.
Reviewable status: 0 of 2 files reviewed, 1 unresolved discussion (waiting on Arcticae).

[orizi]

you would ALWAYS have to state both - these are completely independent concepts.
you could (and mostly should) do it in a oneliner.

#[abi(embed_v0)]
impl ForwardedImpl =
     // The forwarded trait.
     super::ICounterContractForwardImpl<
         ContractState,
         // Where is it forwarded to.
         super::counter_contract::__class_hash__::ForwardingClassHashImpl<ContractState>,
    >;