Files
pezkuwi-subxt/substrate/frame/example
Peter Goodspeed-Niklaus 44d5aba80d Create a macro which automates creation of benchmark test suites. (#8104)
* Create a macro which automates creation of benchmark test suites.

* bump impl_version

* allow unused on test_bench_by_name

* use proper doctest ignore attribute

* Explicitly hand the Module to the test suite

Much better practice than depending on it showing up implicitly in
the namespace.

* explicitly import what we need into `mod tests`

* bench_module is `ident` not `tt`

Co-authored-by: Guillaume Thiolliere <gui.thiolliere@gmail.com>

* allow end users to specify arguments for new_test_ext

This turned out to be surprisingly easy. On reflection, it turns out
that of course the compiler can't eagerly evaluate the function call,
but needs to paste it in everywhere desired.

* enable explicitly specifying the path to the benchmarks invocation

also enable optional trailing commas

* Revert "bump impl_version"

This reverts commit 0209e4de33fd43873f8cfc6875815d0fd6151e63.

* list failing benchmark tests and the errors which caused the failure

* harden benchmark tests against internal panics

* suppress warning about ignored profiles

unfortunately, setting the profile here doesn't do anything; we'd
need to set it in every leaf package anyway. However, as this was
just making the default explicit anyway, I think it's safe enough
to remove entirely.

* impl_benchmark_test_suite for assets

* impl_benchmark_test_suite for balances

* impl_benchmark_test_suite for bounties

* impl_benchmark_test_suite for Collective

* impl_benchmark_test_suite for Contracts

* impl_benchmark_test_suite for Democracy

* don't impl_benchmark_test_suite for Elections-Phragmen

* impl_benchmark_test_suite for Identity

Note that Identity tests currently fail. They failed in an identical
way before this change, so as far as I'm concerned, the status quo is
good enough for now.

* impl_benchmark_test_suite for ImOnline

* impl_benchmark_test_suite for indices

For this crate also, the test suite fails identically with and without
this change, so we can say that this change is not the cause of the
tests' failure to compile.

* impl_benchmark_test_suite for lottery

* impl_benchmark_test_suite for merkle-mountain-range

* impl_benchmark_test_suite for Multisig

These tests fail identically with and without the change, so the change
seems unlikely to be the origin of the failures.

* impl_benchmark_test_suite for offences

* impl_benchmark_test_suite for Proxy

Fails identically with and without this change.

* impl_benchmark_test_suite for scheduler

* impl_benchmark_test_suite for session

It turns out to be important to be able to exclude items marked
`#[extra]` sometimes. Who knew?

* impl_benchmark_test_suite for staking

* impl_benchmark_test_suite for system

* impl_benchmark_test_suite for timestamp

* impl_benchmark_test_suite for tips

* impl_benchmark_test_suite for treasury

* impl_benchmark_test_suite for utility

Note that benchmark tests fail identically before and after this change.

* impl_benchmark_test_suite for vesting

* fix wrong module name in impl_benchmark_test_suite in Offences

* address line length nits

* enable optional keyword argument: exec_name

Took a _lot_ of macro-wrangling to get the functionality that I want,
but now you have the option to pass in

```rust
impl_benchmark_test_suite!(
	Elections,
	crate::tests::ExtBuilder::default().desired_members(13).desired_runners_up(7),
	crate::tests::Test,
	exec_name = build_and_execute,
);
```

and have it expand out properly. A selected fragment of the expansion:

```rust
        fn test_benchmarks() {
            crate::tests::ExtBuilder::default()
                .desired_members(13)
                .desired_runners_up(7)
                .build_and_execute(|| {
```

* get rid of dead code

Co-authored-by: Guillaume Thiolliere <gui.thiolliere@gmail.com>
2021-02-16 10:01:20 +01:00
..
2021-02-10 19:23:18 +01:00
2020-11-30 22:01:18 +00:00

Example Pallet

The Example: A simple example of a FRAME pallet demonstrating concepts, APIs and structures common to most FRAME runtimes.

Run cargo doc --package pallet-example --open to view this pallet's documentation.

Documentation Guidelines:

  • Documentation comments (i.e. /// comment) - should accompany pallet functions and be restricted to the pallet interface, not the internals of the pallet implementation. Only state inputs, outputs, and a brief description that mentions whether calling it requires root, but without repeating the source code details. Capitalize the first word of each documentation comment and end it with a full stop. See Generic example of annotating source code with documentation comments
  • Self-documenting code - Try to refactor code to be self-documenting.
  • Code comments - Supplement complex code with a brief explanation, not every line of code.
  • Identifiers - surround by backticks (i.e. INHERENT_IDENTIFIER, InherentType, u64)
  • Usage scenarios - should be simple doctests. The compiler should ensure they stay valid.
  • Extended tutorials - should be moved to external files and refer to.
  • Mandatory - include all of the sections/subsections where MUST is specified.
  • Optional - optionally include sections/subsections where CAN is specified.

Documentation Template:

Copy and paste this template from frame/example/src/lib.rs into file frame/<INSERT_CUSTOM_PALLET_NAME>/src/lib.rs of your own custom pallet and complete it.

// Add heading with custom pallet name

# <INSERT_CUSTOM_PALLET_NAME> Pallet

// Add simple description

// Include the following links that shows what trait needs to be implemented to use the pallet // and the supported dispatchables that are documented in the Call enum.

  • [<INSERT_CUSTOM_PALLET_NAME>::Trait](https://docs.rs/pallet-example/latest/pallet_example/trait.Trait.html)
  • [Call](https://docs.rs/pallet-example/latest/pallet_example/enum.Call.html)
  • [Module](https://docs.rs/pallet-example/latest/pallet_example/struct.Module.html)

## Overview

// Short description of pallet's purpose. // Links to Traits that should be implemented. // What this pallet is for. // What functionality the pallet provides. // When to use the pallet (use case examples). // How it is used. // Inputs it uses and the source of each input. // Outputs it produces.

## Terminology

// Add terminology used in the custom pallet. Include concepts, storage items, or actions that you think // deserve to be noted to give context to the rest of the documentation or pallet usage. The author needs to // use some judgment about what is included. We don't want a list of every storage item nor types - the user // can go to the code for that. For example, "transfer fee" is obvious and should not be included, but // "free balance" and "reserved balance" should be noted to give context to the pallet. // Please do not link to outside resources. The reference docs should be the ultimate source of truth.

## Goals

// Add goals that the custom pallet is designed to achieve.

### Scenarios

#### <INSERT_SCENARIO_NAME>

// Describe requirements prior to interacting with the custom pallet. // Describe the process of interacting with the custom pallet for this scenario and public API functions used.

## Interface

### Supported Origins

// What origins are used and supported in this pallet (root, signed, none) // i.e. root when `ensure_root` used // i.e. none when `ensure_none` used // i.e. signed when `ensure_signed` used

`inherent` <INSERT_DESCRIPTION>

### Types

// Type aliases. Include any associated types and where the user would typically define them.

`ExampleType` <INSERT_DESCRIPTION>

// Reference documentation of aspects such as storageItems and dispatchable functions should only be // included in the https://docs.rs Rustdocs for Substrate and not repeated in the README file.

### Dispatchable Functions

// A brief description of dispatchable functions and a link to the rustdoc with their actual documentation.

// MUST have link to Call enum // MUST have origin information included in function doc // CAN have more info up to the user

### Public Functions

// A link to the rustdoc and any notes about usage in the pallet, not for specific functions. // For example, in the Balances Pallet: "Note that when using the publicly exposed functions, // you (the runtime developer) are responsible for implementing any necessary checks // (e.g. that the sender is the signer) before calling a function that will affect storage."

// It is up to the writer of the respective pallet (with respect to how much information to provide).

#### Public Inspection functions - Immutable (getters)

// Insert a subheading for each getter function signature

##### `example_getter_name()`

// What it returns // Why, when, and how often to call it // When it could panic or error // When safety issues to consider

#### Public Mutable functions (changing state)

// Insert a subheading for each setter function signature

##### `example_setter_name(origin, parameter_name: T::ExampleType)`

// What state it changes // Why, when, and how often to call it // When it could panic or error // When safety issues to consider // What parameter values are valid and why

### Storage Items

// Explain any storage items included in this pallet

### Digest Items

// Explain any digest items included in this pallet

### Inherent Data

// Explain what inherent data (if any) is defined in the pallet and any other related types

### Events:

// Insert events for this pallet if any

### Errors:

// Explain what generates errors

## Usage

// Insert 2-3 examples of usage and code snippets that show how to // use <INSERT_CUSTOM_PALLET_NAME> Pallet in a custom pallet.

### Prerequisites

// Show how to include necessary imports for <INSERT_CUSTOM_PALLET_NAME> and derive // your pallet configuration trait with the INSERT_CUSTOM_PALLET_NAME trait.

```rust use <INSERT_CUSTOM_PALLET_NAME>;

pub trait Config: <INSERT_CUSTOM_PALLET_NAME>::Config { } ```

### Simple Code Snippet

// Show a simple example (e.g. how to query a public getter function of <INSERT_CUSTOM_PALLET_NAME>)

### Example from FRAME

// Show a usage example in an actual runtime

// See: // - Substrate TCR https://github.com/parity-samples/substrate-tcr // - Substrate Kitties https://shawntabrizi.github.io/substrate-collectables-workshop/#/

## Genesis Config

## Dependencies

// Dependencies on other FRAME pallets and the genesis config should be mentioned, // but not the Rust Standard Library. // Genesis configuration modifications that may be made to incorporate this pallet // Interaction with other pallets

## Related Pallets

// Interaction with other pallets in the form of a bullet point list

## References

// Links to reference material, if applicable. For example, Phragmen, W3F research, etc. // that the implementation is based on.

License: Unlicense