DeprecationInfo Remove deprecated attribute from generated code.
#6312
Conversation
pkhry
added
R0-silent
pkhry
removed
the
T1-FRAME
|
bot fmt |
|
@pkhry https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/7675374 was started for your command Comment |
|
@pkhry Command |
|
/cmd fmt |
|
Command "fmt" has started 🚀 See logs here |
|
Command "fmt" has finished ✅ See logs here |
|
bot update-ui |
|
@pkhry https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/7677803 was started for your command Comment |
|
@pkhry Command |
| @@ -209,6 +210,8 @@ pub fn expand_call(def: &mut Def) -> proc_macro2::TokenStream { | |||
| let return_type = | |||
| &call.methods.get(i).expect("def should be consistent with item").return_type; | |||
|
|
|||
| remove_deprecation_attribute(&mut method.attrs); | |||
There was a problem hiding this comment.
So this removes the deprecated attribute from the call?
I think it is not ideal, because we lose the deprecation of the call itself in rust code.
I think the ideal is to have the deprecation on the call function, also the deprecation on the call variant.
But then all usage of this call inside the macro should be used with #[allow(deprecated)] on top of the instruction. (We should be careful not to have this #[allow(deprecated)] for logic written by user).
There was a problem hiding this comment.
I was thinking a more fine-grained implementation.
Like the dispatch_bypass_filter would be implemented with #[allow(deprecated)] just above the function call
Same for all other types: when the macro use them we would write: #[allow(deprecated)].
But then we have to be careful not to write #[allow(deprecated)] on top of blocks which include code written by user. So that user is still notified when they use deprecated elements in their own code.
If it is too difficult, maybe we can merge this PR, without the revert then.
There was a problem hiding this comment.
I've tried implementing it this morning, and i can't seem to understand how to propagate #[allow(deprecated)] from defs inside #[pallet] to expansion of construct_runtime!. Ie if we deprecate an event or an error we dont have any attributes to include maybe_allow_attrs inside code generated by construct_runtime!
Description
Removed
#[deprecated]attribute from the generated code, so that code is not littered with useless warnings butDeprecationInfois still propagated inMetadataIrsee an example of warnings being too noisy: #6169
Review Notes
The change itself is just adding attribute removal code after specific steps during macro expansion.