Conversation
`generate_constructor_deploy_function` iterated with cfg-unaware `iter_items`, while the main contract loop uses `iter_items_in_cfg`. A constructor behind an inactive #[cfg(...)] was correctly dropped as an entry point but still used to synthesize `deploy_for_test`, producing a test helper with parameters from a constructor that doesn't exist in the build. Thread `cfg_set` into the deploy generation and iterate cfg-aware, matching the main and impl loops. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
This change is |
PR SummaryLow Risk Overview
Reviewed by Cursor Bugbot for commit 545e9ab. Bugbot is set up for automated code reviews on this repo. Configure here. |
TomerStarkware
left a comment
There was a problem hiding this comment.
@TomerStarkware reviewed 2 files and all commit messages, and made 1 comment.
Reviewable status:complete! all files reviewed, all discussions resolved (waiting on eytan-starkware).
Summary
When a
#[constructor]function is annotated with#[cfg(feature: 'xyz')]and that feature is inactive, the constructor was still being picked up bygenerate_constructor_deploy_functionand used to generate thedeploy_for_testfunction. This happened because the body was iterated withiter_itemsinstead ofiter_items_in_cfg, ignoring cfg conditions entirely.The fix passes the active
CfgSetdown togenerate_constructor_deploy_functionandhandle_contract_impl, replacingiter_itemswithiter_items_in_cfgso that constructors (and impl items) behind inactive#[cfg]attributes are correctly excluded.A new test case is added to verify that a constructor behind an inactive
#[cfg(feature: 'xyz')]does not appear in the generated__constructormodule or influencedeploy_for_test.Type of change
Please check one:
Why is this change needed?
A constructor gated behind an inactive
#[cfg]attribute was being included in the generated contract code becauseiter_itemsdoes not respect cfg conditions. This caused incorrect code generation — the inactive constructor's signature would influence thedeploy_for_testhelper, leading to a mismatch between what is actually compiled and what the test infrastructure expects.What was the behavior or documentation before?
generate_constructor_deploy_functioniterated over all module body items unconditionally, so a#[constructor]behind an inactive#[cfg]would still be treated as the contract's constructor when generating test deployment code.What is the behavior or documentation after?
generate_constructor_deploy_functionandhandle_contract_implnow filter items throughiter_items_in_cfg, so only constructors and impl items that are active under the currentCfgSetare considered during code generation.Related issue or discussion (if any)
N/A
Additional context
The
MacroPluginMetadataargument tohandle_contract_implwas narrowed to just&CfgSetsince that is the only field used, which also makes the dependency explicit.