* wasm-builder: Enforce `runtime_version` wasm section
This pr changes the `wasm-builder` to enforce the `runtime_version` wasm section. This wasm section
is being created by the `sp_version::runtime_version` attribute macro. This attribute macro now
exists since quite some time and `runtime_version` also is the only way for parachains to support
reading the `RuntimeVersion` from the runtime.
\# Disabling the check
By default the `WasmBuilder` will now check for this wasm section and if not found, exit with an
error. However, there are situations where you may want to disable this check (like for tests). In
this case there exists the `disable_runtime_version_section_check` function.
```
WasmBuilder::new()
...
...
...
.disable_runtime_version_section_check()
.build()
```
By using this method you get back the old behavior.
* Review comment
* Fix
* Fix issue with `enum-as-inner`
* Change copyright year to 2023 from 2022
* Fix incorrect update of copyright year
* Remove years from copy right header
* Fix remaining files
* Fix typo in a header and remove update-copyright.sh
* Expose allocation stats in `FreeingBumpHeapAllocator`
* Return allocation stats when calling into the runtime
* Bump `parity-scale-codec` to 3.1.3 (fork)
* Prevent double allocation of the payload when calling `sp_io::storage::get`
* Fix tests
* Remove unnecessary `mut`
* Enable the `bytes` feature for `parity-scale-codec` in `sp-runtime-interface`
* Update client/allocator/src/freeing_bump.rs
Co-authored-by: Bastian Köcher <bkchr@users.noreply.github.com>
* Bump `parity-scale-codec` to 3.1.3
* Fix some of the UI tests
Co-authored-by: Bastian Köcher <bkchr@users.noreply.github.com>
* runtime-interface: Implement `register_only` functions
The runtime interface supports versioning of functions. Currently, if you add a new function it will
be used by the runtime automatically. This results in requiring all nodes of a network to upgrade
before the runtime is upgraded, otherwise they will fail to instantiate the new runtime because of
missing host functions. This pr introduces `register_only` functions. This can be used when a new
runtime interface function should be introduced, but the actual usage can be deferred. This means
that nodes will have the host function for this, but the runtime will still use the old version of
the function when being compiled for wasm. However, when a runtime is enacted that uses the new host
function, the "old nodes" will already have the host function and will continue to work.
* Update primitives/runtime-interface/src/lib.rs
Co-authored-by: cheme <emericchevalier.pro@gmail.com>
* Update primitives/runtime-interface/proc-macro/src/utils.rs
Co-authored-by: cheme <emericchevalier.pro@gmail.com>
* FMT
Co-authored-by: cheme <emericchevalier.pro@gmail.com>
* Statically register host WASM functions
* Fix `substrate-test-client` compilation
* Move `ExtendedHostFunctions` to `sp-wasm-interface`
* Fix `sp-runtime-interface` tests' compilation
* Fix `sc-executor-wasmtime` tests' compilation
* Use `runtime_interface` macro in `test-runner`
* Fix `sc-executor` tests' compilation
* Reformatting/`rustfmt`
* Add an extra comment regarding the `H` generic arg in `create_runtime`
* Even more `rustfmt`
* Depend on `wasmtime` without default features in `sp-wasm-interface`
* Bump version of `sp-wasm-interface` to 4.0.1
* Bump `sp-wasm-interface` in `Cargo.lock` too
* Bump all of the `sp-wasm-interface` requirements to 4.0.1
Maybe this will appease cargo-unleash?
* Revert "Bump all of the `sp-wasm-interface` requirements to 4.0.1"
This reverts commit 0f7ccf8e0f371542861121b145ab87af6541ac30.
* Make `cargo-unleash` happy (maybe)
* Use `cargo-unleash` to bump the crates' versions
* Align to review comments
* Introduce `SecretUri`
* `inspect-key`: Adds support for `expect-public`
`expect-public` can be used to check that a given secret uri corresponds to the given public key.
This is mainly useful when the secret uri is protected by a password and a new derived account
should be generated. With `--expect-public` the user can pass the public key/account-id of the
"base" secret uri aka the one without any derivation to ensure the correct password was inserted.
* Fixes
* 🤦
* Apply suggestions from code review
Co-authored-by: André Silva <123550+andresilva@users.noreply.github.com>
* Review feedback
* FMT
* Bump the versions
Co-authored-by: André Silva <123550+andresilva@users.noreply.github.com>
* Run cargo fmt on the whole code base
* Second run
* Add CI check
* Fix compilation
* More unnecessary braces
* Handle weights
* Use --all
* Use correct attributes...
* Fix UI tests
* AHHHHHHHHH
* 🤦
* Docs
* Fix compilation
* 🤷
* Please stop
* 🤦 x 2
* More
* make rustfmt.toml consistent with polkadot
Co-authored-by: André Silva <andrerfosilva@gmail.com>
* mark template and utils as non-publish
* switch to development version for testing
* activate unleash check
* maybe if I disable all rules...
* Fix isolated compilation of `max-encoded-len-derive` with `syn`
error[E0369]: binary operation `==` cannot be applied to type `syn::Path`
--> src/lib.rs:88:29
|
88 | .filter(|attr| attr.path == parse_quote!(max_encoded_len_crate))
| --------- ^^ ----------------------------------- _
| |
| syn::Path
error: aborting due to previous error
For more information about this error, try `rustc --explain E0369`.
Error: could not compile `max-encoded-len-derive`
* WIP: bump changes crates since v3 tag to next breaking
cargo unleash version bump-breaking --changed-since v3.0.0
cargo unleash version set-pre dev --changed-since v3.0.0
FIXME: Don't modify crates that are not yet released, e.g.
`max-encoded-len-derive`
* Update lockfile
* WIP: Bump sp-transaction-pool as well
* WIP: Bump sp-offchain as well
* WIP: Bump frame-system-rpc-runtime-api as well
* WIP: Bump sp-authority-discovery as well
* Manually deactivate dev-deps before `cargo unleash check`
Otherwise we run into `Cycle detected` error.
* Bump sp-consensus-slots
* Add missing Cargo.lock change
* Bump sp-consensus-vrf as well
* Bump sp-keyring as well
* Bump sp-consensus-pow as well
* Try to speed up the `unleash-check` job
Previously, the job took 106 minutes - let's see if explicitly
specifying a `CARGO_TARGET_DIR` will help
* fixup: Ensure the temp target dir exists for unleash check
* Bump pallet-transaction-payment-rpc-runtime-api as well
Needed for Polkadot
* Bump pallet-transaction-payment-rpc as well
Needed for Polkadot
* Try updating crates after patching in the Polkadot CI job
* Use another approach to update patched Substrate crates
* Try to update all sp-core versions in Polkadot CI job
* Simplify sp-core version checking
* Apply another shellcheck lint
* Just do the simplest thing I guess
* Welp don't do --offline then
* Clean up `unleash-check` job triggers
Co-authored-by: Denis Pisarev <denis.pisarev@parity.io>
* Fix a note in unleash-check cache step
* Add a note about temporary optimization in cargo-unleash
* Pin a newer version of cargo-unleash
Co-authored-by: Igor Matuszewski <xanewok@gmail.com>
Co-authored-by: Denis Pisarev <denis.pisarev@parity.io>
* Build every wasm crate in its own project with wasm-builder
Building all wasm crates in one workspace was a nice idea, however it
just introduced problems:
1. We needed to prune old members, but this didn't worked for old git
deps.
2. We locked the whole wasm workspace while building one crate. This
could lead to infinitely locking the workspace on a crash.
Now we just build every crate in its own project, this means we will
build the dependencies multiple times. While building the dependencies
multiple times, we still decrease the build time by around 30 seconds
for Polkadot and Substrate because of the new parallelism ;)
* Remove the requirement on wasm-builder-runner
This removes the requirement on wasm-builder-runner by using the new
`build_dep` feature of cargo. We use nightly anyway and that enables us
to use this feature. This solves the problem of not mixing
build/proc-macro deps with normal deps. By doing this we get rid off
this complicated project structure and can depend directly on
`wasm-builder`. This also removes all the code from wasm-builder-runner
and mentions that it is deprecated.
* Copy the `Cargo.lock` to the correct folder
* Remove wasm-builder-runner
* Update docs
* Fix deterministic check
Modified-by: Bastian Köcher <git@kchr.de>
* Try to make the ui test happy
* Switch to `SKIP_WASM_BUILD`
* Rename `SKIP_WASM_BINARY` to the correct name...
* Update utils/wasm-builder/src/builder.rs
Co-authored-by: André Silva <123550+andresilva@users.noreply.github.com>
* Update utils/wasm-builder/src/builder.rs
Co-authored-by: André Silva <123550+andresilva@users.noreply.github.com>
Co-authored-by: André Silva <123550+andresilva@users.noreply.github.com>
* Fixes bug in wasm-builder with cargo publish
There was a bug in wasm-builder which resulted in generating a
`Cargo.lock` in the project directory because of running `cargo
metadata`. This resulted in commands like `cargo publish` to fail (if
there was no `Cargo.lock` before building), because it checks that the
project directory isn't modified.
* Update utils/wasm-builder/src/wasm_project.rs
Co-authored-by: André Silva <123550+andresilva@users.noreply.github.com>
Co-authored-by: André Silva <123550+andresilva@users.noreply.github.com>
* Release new version of wasm-builder-runner
Besides the new version this merges `SKIP_WASM_BUILD` and
`BUILD_DUMMY_WASM_BINARY`, this means a file is generated with
`SKIP_WASM_BUILD` if no file existed before.
* Update utils/wasm-builder-runner/Cargo.toml
* Update utils/wasm-builder-runner/src/lib.rs
Co-authored-by: André Silva <123550+andresilva@users.noreply.github.com>
* Update versions
Co-authored-by: André Silva <123550+andresilva@users.noreply.github.com>
* Bump version
* update test-utils crates to be ready for publishing
* adding changelog
* Adding automaticly generated READMEs
* fixing versions
* another version mishap
* Enable the `runtime-wasm` for wasm builds
This enables the `runtime-wasm` feature for wasm builds. The feature is
not mandatory and will only be activated if it exists in the
`Cargo.toml`.
* Fix compilation
* Update docs
* Uprgade version
* Apply suggestions from code review
Oliver Tale-Yazdi