-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Conversation
127e0bb
to
dc5050b
Compare
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.
Would be cool to have a UI test ensuring that it complains if you try to provide an argument to #[hold_reason(..)]
since none are supported
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.
how generalize can we make this be?
what happen if we need a freeze reason? withdraw reason?
a Task for the omni scheduler?
I could add slash reason/reserve reason/lock ID within this PR, but it's best to check and see whether this approach is good first. And as Basti has mentioned in this comment, it makes sense to have separate attributes for different things. |
If we want to add those now, it would require us to pretty much copy paste the existing diff with new names. Could it be that under the hood we have a general system for a pallet to define "composite_parts", but statically only allow it to be As for Basti's comment, If the main reason is that typos are hard to detect, I think the can manually check it by having I won't strongly push back on this either as the broad currency refactor is greatly more important, but I want to bring it up one more time before heading to review and merge. |
Yeah this is a very useful pattern and I want to make sure this feature not only available to core pallets. For example, ORML may want to define some LockReason enum. We cannot do it without modify some low level FRAME code. It will be great if this macro can be implemented in such way that users can define custom enum type. Something like |
With the latest commit, the code now supports an attribute called
However, even with the problems listed above, the basic infrastructure of supporting arbitrary aggregate enum identifiers are in place, and it should take less effort to parse and expand them when we figure out the best way to resolve the aforementioned issues. |
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.
re-reviewed for composite stuff, 👍🏻
// distributed under the License is distributed on an "AS IS" BASIS, | ||
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. | ||
// See the License for the specific language governing permissions and | ||
// limitations under the License. |
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.
This is great for our purposes. I wonder, though, how easy would it be for an outside user to add a custom composite for, say, their own parachain? Would they have to patch this file?
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.
They'd actually have to do a little more stuff:
- Modify the parser in
construct_runtime
so that it knows how to scan for the existence of a new aggregate enum via a new pallet part. - Instruct
construct_runtime
to check for the new pallet part and expanding it into the aggregate enum, complete with conversion functions as well. - Scan for all pallets during the expansion mentioned in 2 for any other pallets that contain the new pallet part, and aggregate all of them into an aggregated enum.
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 there a way to reduce code duplication?
Maybe use a decl macro?
bot merge |
* Implement #[pallet::hold_reason] * Appease clippy * cargo fmt * Update test expectations * Update test expectations * Support composite_enum attribute instead * Update test expectations * Change hold_reason to composite_enum * Add UI test for unsupported identifier when using composite_enum * Fix comment * Add documentation for pallet::composable_enum * More docs * cargo fmt
This pull request has been mentioned on Polkadot Forum. There might be relevant details there: https://forum.polkadot.network/t/april-updates-for-substrate-and-polkadot-devs/2764/1 |
* Implement #[pallet::hold_reason] * Appease clippy * cargo fmt * Update test expectations * Update test expectations * Support composite_enum attribute instead * Update test expectations * Change hold_reason to composite_enum * Add UI test for unsupported identifier when using composite_enum * Fix comment * Add documentation for pallet::composable_enum * More docs * cargo fmt
Partial paritytech/polkadot-sdk#236.
This PR adds a couple of new pallet parts:
FreezeReason
,HoldReason
,LockId
andSlashReason
. The corresponding aggregate enumsRuntimeFreezeReason
,RuntimeHoldReason
,RuntimeLockId
andRuntimeSlashReason
are also generated byconstruct_runtime
. This is primarily used in pallets that wish to provide a reason for freezing funds, holding funds, locking funds and/or slashing funds in them.#[pallet::composite_enum]
is also added as an attribute to put on top of an enum declared in a pallet module. It now only acceptsFreezeReason
,HoldReason
,LockId
andSlashReason
as identifiers for the enum; any other identifier gets rejected during pallet attribute parsing. If there are no#[derive]
attributes marked for the enum, the code would then automatically add derives for theCopy, Clone, Eq, PartialEq, Ord, PartialOrd, Decode, Encode, MaxEncodedLen, RuntimeDebug, TypeInfo
traits.