Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

undetected unused variables in frame benchmarking V1 #6078

Open
kianenigma opened this issue Oct 15, 2024 · 5 comments
Open

undetected unused variables in frame benchmarking V1 #6078

kianenigma opened this issue Oct 15, 2024 · 5 comments
Labels
T1-FRAME This PR/Issue is related to core FRAME, the framework.

Comments

@kianenigma
Copy link
Contributor

Merging of #6018 made some unused variable imports to appear in the code. I first thought @re-gius had some mistake, but it is not the case. Looking at the old benchmarking code, it seems like some variables are indeed unused, and it goes undetected in the v1 benchmarking macro.

In the v2 macro, it gets detected though.

Example: call_hash and multi_account_id here:

as_multi_threshold_1 {
// Transaction Length
let z in 0 .. 10_000;
let max_signatories = T::MaxSignatories::get().into();
let (mut signatories, _) = setup_multi::<T>(max_signatories, z)?;
let call: <T as Config>::RuntimeCall = frame_system::Call::<T>::remark {
remark: vec![0; z as usize]
}.into();
let call_hash = call.using_encoded(blake2_256);
let multi_account_id = Multisig::<T>::multi_account_id(&signatories, 1);
let caller = signatories.pop().ok_or("signatories should have len 2 or more")?;
// Whitelist caller account from further DB operations.
let caller_key = frame_system::Account::<T>::hashed_key_for(&caller);
frame_benchmarking::benchmarking::add_to_whitelist(caller_key.into());
}: _(RawOrigin::Signed(caller.clone()), signatories, Box::new(call))
verify {
// If the benchmark resolves, then the call was dispatched successfully.
}
as_multi_create {

@kianenigma kianenigma added the T1-FRAME This PR/Issue is related to core FRAME, the framework. label Oct 15, 2024
@runcomet
Copy link

@kianenigma removal of this footgun is needed?

@kianenigma
Copy link
Contributor Author

We would first need to understand what is the disparity between v1 and v2 syntax that is causing this. Then, yes, fixing it is needed.

@ggwpez
Copy link
Member

ggwpez commented Oct 17, 2024

In the V2 syntax we actually expand these code of blocks into proper functions. We end up not using those functions, but they are annotated with the same spans as the original code, getting us proper clippy warning support.

I dont remember how it works in the V1 code, but i think "unused warnings" are normally ignored in macro expanded code, so that could be it.
Depending on the time it takes to fix this, maybe its better to port more pallets to the V2 syntax. We eventually want to remove the old syntax...

@runcomet
Copy link

Locating the issue while porting more pallets to V2 seems like two birds one long weekend :) but could then see which pallets generate the warning?

@ggwpez
Copy link
Member

ggwpez commented Oct 23, 2024

The tracking issue for moving them is here: #6202

but could then see which pallets generate the warning?

Yes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T1-FRAME This PR/Issue is related to core FRAME, the framework.
Projects
None yet
Development

No branches or pull requests

3 participants