-
Notifications
You must be signed in to change notification settings - Fork 2.7k
Relocate weight to paint + decouple from extensions #4124
Conversation
paint/elections-phragmen/Cargo.toml
Outdated
| sr-primitives = { path = "../../primitives/sr-primitives", default-features = false } | ||
| phragmen = { package = "substrate-phragmen", path = "../../primitives/phragmen", default-features = false } | ||
| paint-support = { path = "../support", default-features = false } | ||
| support = { package = "paint-support", path = "../support", default-features = false } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
as soon as names are settled, one should make a PR and unify all of such imports.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought we no longer want to do renames?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
indeed, but see my note:
as soon as names are settled, one should make a PR and unify all of such imports.
at least now that almost everywhere we use paint-support as support, having consistency is better IMO + makes sed-ing much easier. As mentioned, I'm more than happy to kill all of these as soon as we are done with paint -> palette.
paint/elections-phragmen/Cargo.toml
Outdated
| sr-primitives = { path = "../../primitives/sr-primitives", default-features = false } | ||
| phragmen = { package = "substrate-phragmen", path = "../../primitives/phragmen", default-features = false } | ||
| paint-support = { path = "../support", default-features = false } | ||
| support = { package = "paint-support", path = "../support", default-features = false } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought we no longer want to do renames?
| FunctionMetadata, DecodeDifferent, DecodeDifferentArray, FunctionArgumentMetadata, | ||
| ModuleConstantMetadata, DefaultByte, DefaultByteGetter, ModuleErrorMetadata, ErrorMetadata | ||
| }; | ||
| pub use crate::weights::{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it really worth to re-export? This stuff is in the same crate, I don't see a point - it will just introduce ambiguity.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AFAIK: This stuff, similar to other re-exports of the module are needed to be accessed from within the macro. I learned this by example. @bkchr can probably either explain more or correct me.
| pub trait Trait: system::Trait { | ||
| /// The currency type in which fees will be paid. | ||
| type Currency: Currency<Self::AccountId>; | ||
| type Currency: Currency<Self::AccountId> + Send + Sync; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you elaborate why is Send + Sync required? I wouldn't expect to see that in any part of runtime.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point, I didn't really care much since I have seen these two in all SignedExtension type. For instance:
substrate/paint/system/src/lib.rs
Line 853 in 0f87c92
| impl<T: Trait + Send + Sync> SignedExtension for CheckWeight<T> { |
So I assumed it is okay. But I will look it up.
although, we use Send + Sync in Member which is used around the runtime, so just by observation, I would not assume that we ban them in runtime. Although it does makes sense that a single threaded runtime should not really need them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Needed due to AccountId being Member.
| type Pre: Default; | ||
|
|
||
| /// An opaque set of information attached to the transaction. | ||
| type Info: Copy; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Copy is a pretty strict, why not just Clone?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did face the dilemma and at the time the rational was: while we are making Type Info be generic but we currently know that we'll use it with a type that has Copy and this makes the syntax much much easier for now. If we see Copy as merely a marker that clone is cheap, I think it is fair to say that this bundled information will always be cheap to copy.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
naah made it clone, was easier than what I thought to refactor.
|
will need some minor refactoring in polkadot |
Co-Authored-By: Bastian Köcher <[email protected]>
Co-Authored-By: Bastian Köcher <[email protected]>
Makes
SignedExtensionindependent of the type of the weight data, allowing a potential user to actually not have any sort of weight or class by settingtype Info = ().Moves the weight related stuff to support, since they are part of our opinionated runtime.
Looks like we need a follow up PR to move all the extrinsic stuff to paint, but I'll do that in a follow up, since this has a bit of logic change in signed extension.