Working towards migrating the `parity-bridges-common` repo inside
`polkadot-sdk`. This PR upgrades some dependencies in order to align
them with the versions used in `parity-bridges-common`
Related to
https://github.com/paritytech/parity-bridges-common/issues/2538
Changes (partial https://github.com/paritytech/polkadot-sdk/issues/994):
- Set log to `0.4.20` everywhere
- Lift `log` to the workspace
Starting with a simpler one after seeing
https://github.com/paritytech/polkadot-sdk/pull/2065 from @jsdw.
This sets the `default-features` to `false` in the root and then
overwrites that in each create to its original value. This is necessary
since otherwise the `default` features are additive and its impossible
to disable them in the crate again once they are enabled in the
workspace.
I am using a tool to do this, so its mostly a test to see that it works
as expected.
---------
Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
We currently use a bit of a hack in `.cargo/config` to make sure that
clippy isn't too annoying by specifying the list of lints.
There is now a stable way to define lints for a workspace. The only down
side is that every crate seems to have to opt into this so there's a
*few* files modified in this PR.
Dependencies:
- [x] PR that upgrades CI to use rust 1.74 is merged.
---------
Co-authored-by: joe petrowski <25483142+joepetrowski@users.noreply.github.com>
Co-authored-by: Branislav Kontur <bkontur@gmail.com>
Co-authored-by: Liam Aharon <liam.aharon@hotmail.com>
Using taplo, fixes all our broken and inconsistent toml formatting and
adds CI to keep them tidy.
If people want we can customise the format rules as described here
https://taplo.tamasfe.dev/configuration/formatter-options.html
@ggwpez, I suggest zepter is used only for checking features are
propagated, and leave formatting for taplo to avoid duplicate work and
conflicts.
TODO
- [x] Use `exclude = [...]` syntax in taplo file to ignore zombienet
tests instead of deleting the dir
---------
Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
Co-authored-by: Bastian Köcher <git@kchr.de>
* #10576: refactor `sc-utils::notification` and `sc-client-api::notifications`, so that they use common subscribe/unsubscribe routines
* Add some docs. Reorganise `sc-utils::notification`
* `sc-clent-api::notifications` and `sc-utils::notification` — ensure the SubscriptionGuard is dropped before the Rx-channel
* `sc-utils::pubsub::SubscriptionGuard` make it a bit more ergonomic.
Let the `Rx` to be put inside of the `SubscriptionGuard`, so that the latter shall guarantee the order:
- first unsubscribe;
- then drop the `Rx`.
* Being less zealous with splitting the modules into little pieces
* rework pubsub: the concrete usage should only define a good registry type
* sc-client-api::notifications: make it comply with the reworked pubsub
* cargo fmt
* make sc-client-api tests work
* Address the review notes
* cargo fmt
* Describe the behaviour of pubsub registry
* Doc-comments for module `sc-utils::pubsub`
* Fix: it used to send notifications regardless of the filter setup during subscription
* `sc-client-api::StorageNotifications` the API does not have to require mut-self-reference.
As a result `sc-service::Client` does not have to wrap its `storage_notifications` into a Mutex.
* cargo fmt
* Several changes addressing the notes by @bckhr.
- Remove the `impl Default for StorageNotifications<Block>`;
- no need for groupping the `remove_from` and `listen_from` into a separate `helpers` module;
- remove unnecessary import `use registry::SubscribeOp`.
* Add a doc-comment to the `sc-client::notifications::SubscribeOp`
* As per @bkchr note on the unproven assertion: behave gracefully upon receiving a duplicate subscription-ID.
* sc-utils::pubsub: log when a registry yields an ID that does point to an existing sink
* `sc-utils::notifications`: payload materialized lazily
* Update Cargo.lock (after adding `log` as a dependency to the `sc-utils`)
* `sc-client-api::notifications`: introduce a struct (instead of a type def) for the notification message
* Get rid of `sc-utils::pubsub::Channel` trait (instead just use the `sc-utils::mpsc`)
* The SubsID is no more generic: the fact it is a `Copy` is known — no need to pass it by ref
* sc-utils::pubsub internals do not have to be generic over the channel type
* Rename Hub::dispatch into Hub::send
* That method was unnecessary (`SubscriberSink::render_notification`)
* cargo fmt
* No need for a separate UnsubscribeGuard type
* Ditch the type-def of SubsID in the sc-utils::pubsub, instead — just use the crate::id_sequence::SeqID
* Return the <Registry as Dispatch>::Ret when sending an item
* Make the `Hub<M, R>::lock_registry(...)` method more ergonomic
* cargo doc links
* cargo doc links
* Use a simpler name for the type
* cargo doc links
* Derive `Default` rather than implement it
* Derive `Default` rather than implement it
* Remove an unnecessary usage of type_name
* Define a more cautious order between sinks.remove->registry.unsubscribe and registry.subscribe->sinks.insert
* Hub: lock_registry_for_tests->map_registry_for_tests — a safer choice for a public API
* Replace Mutex over the shared Registry with a ReentrableMutex+RefCell
* sc-utils::pubsub: add tests for a panicking registry
* Add the missing copyright headers
* Arc<Vec<_>> -> Arc<[_]>
* Upgraded dependencies
* Adapting code to scale v3
* Empty commit to trigger CI
* Triggering CI
* Fixing UI test
* Remove superfluous dev-dep added by #9228
* Cryout for CI
* beefy: add dummy latest_finalized() RPC
* beefy: rpc latest_best_beefy() using shared mem
* beefy: rpc populate latest_best_beefy()
* beefy: rpc handle readiness
* beefy: best block over channel - wip
Not working because channel can't be simply opened and receiver passed
to `rpc_extensions_builder` because `rpc_extensions_builder` has to be
`Fn` and not `FnOnce`... and and Receiver side of mpsc can't be cloned
yay!..
* beefy: make notification channels payload-agnostic
* beefy: use notification mechanism instead of custom channel
* beefy: add tracing key to notif channels
* sc-utils: add notification channel - wip
* beefy: use sc-utils generic notification channel
* grandpa: use sc-utils generic notification channel
* fix grumbles
* beefy-rpc: get best block header instead of number
* beefy-rpc: rename to `beefy_getFinalizedHead`
* fix nitpicks
* client-rpc-notifications: move generic Error from struct to fn
* beefy: use header from notification instead of getting from database
* beefy-rpc: get best block hash instead of header
* beefy-rpc: fix and improve latestHead test
* beefy-rpc: bubble up errors from rpc-handler instantiation
* update lockfile
* Apply suggestions from code review
Co-authored-by: André Silva <123550+andresilva@users.noreply.github.com>
* fix errors and warnings
* fix nit
Co-authored-by: André Silva <123550+andresilva@users.noreply.github.com>
* Intend to reactivate cargo-unleash check
It appears the bug it was deactivated for has been resolved a while ago. Trying to reactivate the checks.
* adding missing cargo.toml metadata for BEEFY crates
* fix wrong version reference
* matching up versions
* disable faulty cache
* switching more versions to prerelease
* Revert "disable faulty cache"
This reverts commit 411a12ae444a9695a8bfea4458a868438d870b06.
* bump minor of sc-allocator to fix already-published-issue
* fixup another pre-released dependency problem
* temp switch to latest unleash
* fixing dependency version and features
* prometheus endpoint has also been changed
* fixing proposer metrics versioning
* fixing hex feature for beefy
* fix generate-bags feature selection
* fixup Cargo.lock
* upgrade prometheus dependencies
* missed one
* switch to latest release
* sp-utils => sc-utils
* cargo fmt
* These files are now in the client so should be licensed as GPL3
* Apply suggestions from code review
Co-authored-by: Bastian Köcher <bkchr@users.noreply.github.com>
Serban Iorga