* Impl InherentDataProviderExt for more tuples
Currently the inherent data provider only supports up to 4 entries due to the limit of
InherentDataProviderExt, which is not enough for a chain with more than 4 inherent data providers.
This patch simply impls InherentDataProviderExt for more tuples.
* Nit
* Apply suggestions from code review
Co-authored-by: André Silva <123550+andresilva@users.noreply.github.com>
Co-authored-by: Guillaume Thiolliere <gui.thiolliere@gmail.com>
Co-authored-by: André Silva <123550+andresilva@users.noreply.github.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>
* NaN canonicalization
* Introduce a simple stack depth metering
* Be explicit about the wasm features we enable
* Pull the latest latast fix for the pwasm-utils crate
* Disable `wasm_threads` as well.
* Factor out deterministic stack params
* Add more docs
* Remove redundant dep
* Refine comments
* Typo
Co-authored-by: Andronik Ordian <write@reusable.software>
Co-authored-by: Andronik Ordian <write@reusable.software>
* Add function for embedding the runtime version in a wasm blob
This function can be used to add the custom section to a wasm blob with
the runtime version in it.
* Review nitpick
* bump a bunch of deps in parity-common
* primitive-types 0.10.0
* update Cargo.lock
* downgrade a few more
* this is unlikely to help
* try something
* Checkmate, Atheists!
* Do not call `initialize_block` before any runtime api
Before this change we always called `initialize_block` before calling
into the runtime. There was already support with `skip_initialize` to skip
the initialization. Almost no runtime_api requires that
`initialize_block` is called before. Actually this only leads to higher
execution times most of the time, because all runtime modules are
initialized and this is especially expensive when the block contained a
runtime upgrade.
TLDR: Do not call `initialize_block` before calling a runtime api.
* Change `validate_transaction` interface
* Fix rpc test
* Fixes and comments
* Some docs
* Move alloc primitive (not used in /pallets)
* Move to alternative location as not shared
* moved crates to different dir
* ren sp_chain_spec to sc_chain_spec_primatives
* merged sc-chain-spec and moved allocation up one.
* no no_std
* nudge
* Bump CI
* Make it possible to override maximum payload of RPC
* Finish it.
* remove todo.
* Update client/cli/src/commands/run_cmd.rs
* Apply suggestions from code review
Co-authored-by: David <dvdplm@gmail.com>
* Apply suggestions from code review
Co-authored-by: David <dvdplm@gmail.com>
* Incorporate suggestions
* Thread rpc_max_payload from configuration to trace_block
* Try obey line gitlab/check_line_width.sh
* update state rpc tests
* Improve readbility
* Apply suggestions from code review
* Apply suggestions from code review
Co-authored-by: Bastian Köcher <bkchr@users.noreply.github.com>
Co-authored-by: Zeke Mostov <32168567+emostov@users.noreply.github.com>
Co-authored-by: David <dvdplm@gmail.com>
This instructs the Aura runtime api to skip initialize block, when
requesting the authorities. This is important, as we don't want to use
the new authorities that should be used from the next block on.
Besides that, it removes the caching stuff. The cache is not available
on full nodes anyway. In the future we should store the authorities
probably in the aux store.
* Decommit instance memory after a runtime call on Linux
* Update documentation for the test
* Remove unfinished comment
* Use saturating_sub.
Also update the doc comment.
* Precise RSS tracking in the test
Instead of tracking RSS for the whole process we just look at the particular mapping that is associated with the linear memory of the runtime instance
* Remove unused import
* Fix unused imports
* Fix the unused imports error for good
* Rollback an accidental change to benches
* Fix the test
* Remove now unneeded code
* Transaction pool: Remove futures-diagnose and thread pool
This pr removes `futures-diagnose` as this isn't used anymore. Besides
that the pr also removes the thread pool that was used to validate the
transactions in the background. Instead of this thread pool we now spawn
two separate long running tasks that we use to validate the
transactions. All tasks of the transaction pool are now also spawned as
essential tasks. This means, if any of these tasks is stopping, the node
will stop as well.
* Update client/transaction-pool/src/api.rs
* Migrate ProfilingLayer to tracing registry API
* Remove the `current_span` field from `BlockSubscriber`.
* Bump the `tracing-subscriber` version
* Fix Gitlab CI
Arkadiy Paronyan