Application microframework with command-line option parsing, configuration, error handling, logging, and shell interactions

iqlusion

Last update: Dec 26, 2022

Related tags

Command-line abscissa

Overview

Abscissa is a microframework for building Rust applications (either CLI tools or network/web services), aiming to provide a large number of features with a minimal number of dependencies, and with a strong focus on security.

Documentation

Features

command-line option parsing: simple declarative option parser based on gumdrop. The option parser in Abcissa contains numerous improvements which provide better UX and tighter integration with the other parts of the framework (e.g. overriding configuration settings using command-line options).
components: Abscissa uses a component architecture (similar to an ECS) for extensibility/composability, with a minimalist implementation that still provides such features such as calculating dependency ordering and providing hooks into the application lifecycle. Newly generated apps use two components by default: terminal and logging.
configuration: Simple parsing of TOML configurations to serde-parsed configuration types which can be dynamically updated at runtime.
error handling: unified error-handling subsystem with generic error type.
logging: based on the log to provide application-level logging.
secrets management: the (optional) secrets module includes a Secret type which derives serde's Deserialize and can be used to represent secret values parsed from configuration files or elsewhere (e.g. credentials loaded from the environment or network requests)
terminal interactions: support for colored terminal output (with color support autodetection). Useful for Cargo-like status messages with easy-to-use macros.

Projects Using Abscissa

Canister: deployment utility for "distroless" containers/microVMs
cargo-audit: audit Cargo projects for security vulnerabilities
cargo-rpm: build RPMs out of Cargo projects
cosmon: observability tool for Tendermint applications
ibc-rs: Rust implementation of Interblockchain Communication (IBC) modules and relayer
OpenLibra: open platform for financial inclusion. Not run by Facebook.
Synchronicity: distributed build system providing BFT proofs-of-reproducibility
Tendermint KMS: key management system for Tendermint applications
Zebra: Rust implementation of a Zcash node
Zerostash: Encrypted and deduplicated backups

Crate Structure

Abscissa presently consists of three crates:

abscissa: CLI app and application generator - cargo install abscissa
abscissa_core: main framework library
abscissa_derive: custom derive support - implementation detail of abscissa_core
abscissa_tokio: support for launching Tokio runtimes within Abscissa applications

Minimum Supported Rust Version

Requires Rust 1.56 or newer.

Installation

To generate a new Abscissa application, install the abscissa CLI utility:

$ cargo install abscissa

Usage

After installing the abscissa CLI utility using the method above, run abscissa new <my_app> to generate a new application:

This will generate a new Abscissa application in the my_cool_app directory. For more information, please see the Documentation.

Depencencies

or: "Know Your Dependencies"

One of Abscissa's primary goals is to maximize functionality while minimizing the number of dependencies. Abscissa is used in a number of high-security contexts, and as such we view each additional dependency as additional attack surface and therefore a potential liability. We have therefore been very conscientious about the dependencies we use and will not add additional dependencies without due consideration.

Here are all of Abscissa's transitive dependencies when configured with the default set of features in the application:

#	Crate Name	Origin	License	Description
1	abscissa_core	iqlusion	Apache-2.0	Abscissa framework
2	aho-corasick	@BurntSushi	MIT/Unlicense	Pattern-matching alg
3	ansi_term	@ogham	MIT	Terminal color libray
4	arc-swap	@vorner	Apache-2.0/MIT	Atomic swap for `Arc`
5	atty	@softprops	MIT	Detect TTY presence
6	autocfg	@cuviper	Apache-2.0/MIT	Rust compiler configs
7	backtrace	@alexcrichton	Apache-2.0/MIT	Capture stack traces
8	backtrace-sys	@alexcrichton	Apache-2.0/MIT	Capture stack traces
9	byteorder	@BurntSushi	MIT/Unlicense	Byte order conversions
10	canonical-path	iqlusion	Apache-2.0	Get canonical fs paths
11	chrono	chronotope	Apache-2.0/MIT	Time/date library
12	color-backtrace	@athre0z	Apache-2.0/MIT	Rich colored backtraces
13	fs-err	@andrewhickman	Apache-2.0/MIT	Better filesystem errors
14	generational-arena	@fitzgen	MPL-2.0	Component allocator
15	gumdrop	@Murarth	Apache-2.0/MIT	Command-line options
16	lazy_static	rust-lang	Apache-2.0/MIT	Heap-allocated statics
17	libc	rust-lang	Apache-2.0/MIT	C library wrapper
18	log	rust-lang	Apache-2.0/MIT	Logging facade library
19	matchers	@hawkw	MIT	Stream regex matching
20	maybe-uninit	@est31	Apache-2.0/MIT	MaybeUninit compat
21	memchr	@BurntSushi	MIT/Unlicense	Optimized byte search
22	num-integer	rust-num	Apache-2.0/MIT	`Integer` trait
23	num-traits	rust-num	Apache-2.0/MIT	Numeric traits
24	once_cell	@matklad	Apache-2.0/MIT	Single assignment cells
25	redox_syscall	redox-os	MIT	Redox OS syscall API
26	regex	rust-lang	Apache-2.0/MIT	Regular expressions
27	regex-automata	@BurntSushi	MIT/Unlicense	Low-level regex DFAs
28	regex-syntax	rust-lang	Apache-2.0/MIT	Regex syntax impl
29	rustc-demangle	@alexcrichton	Apache-2.0/MIT	Symbol demangling
30	secrecy	iqlusion	Apache-2.0	Secret-keeping types
31	semver	@steveklabnik	Apache-2.0/MIT	Semantic versioning
32	semver-parser	@steveklabnik	Apache-2.0/MIT	Parser for semver spec
33	serde	serde-rs	Apache-2.0/MIT	Serialization framework
34	sharded-slab	@hawkw	MIT	Concurrent slab allocator
35	signal-hook	@vorner	Apache-2.0/MIT	Unix signal handling
36	signal-hook-registry	@vorner	Apache-2.0/MIT	Unix signal registry
37	smallvec	servo	Apache-2.0/MIT	Optimized small vectors
38	termcolor	@BurntSushi	MIT/Unlicense	Terminal color support
39	thread_local	@Amanieu	Apache-2.0/MIT	Per-object thread local
40	time	rust-lang	Apache-2.0/MIT	Time/date library
41	toml	@alexcrichton	Apache-2.0/MIT	TOML parser library
42	tracing	tokio-rs	MIT	App tracing / logging
43	tracing-core	tokio-rs	MIT	App tracing / logging
44	tracing-log	tokio-rs	MIT	`log` compatibility
45	tracing-subscriber	tokio-rs	MIT	Tracing subscribers
46	utf8-ranges	@BurntSushi	MIT/Unlicense	UTF-8 codepoint ranges
47	winapi§	@retep998	Apache-2.0/MIT	Windows FFI bindings
48	winapi-util	@BurntSushi	MIT/Unlicense	Safe winapi wrappers
49	wincolor	@BurntSushi	MIT/Unlicense	Windows console color
50	zeroize	iqlusion	Apache-2.0/MIT	Zero out sensitive data

Build / Development / Testing Dependencies

#	Crate Name	Origin	License	Description
1	abscissa_derive	iqlusion	Apache-2.0	Abscissa custom derive
2	cc	@alexcrichton	Apache-2.0/MIT	C/C++ compiler wrapper
3	cfg-if	@alexcrichton	Apache-2.0/MIT	If-like `#[cfg]` macros
4	darling	@TedDriggs	MIT	Nifty attribute parser
5	darling_core	@TedDriggs	MIT	Attribute parser core
6	darling_macro	@TedDriggs	MIT	Attribute parser macros
7	fnv	@alexcrichton	Apache-2.0/MIT	Fast hash function
8	gumdrop_derive	@Murarth	Apache-2.0/MIT	Command-line options
9	ident_case	@TedDriggs	Apache-2.0/MIT	Case conversion utils
10	proc-macro2	@alexcrichton	Apache-2.0/MIT	Shim for Macros 2.0 API
11	quote	@dtolnay	Apache-2.0/MIT	Rust AST to token macro
12	serde_derive	serde-rs	Apache-2.0/MIT	`serde` custom derive
13	strsim	@dguo	MIT	String similarity utils
14	syn	@dtolnay	Apache-2.0/MIT	Rust source code parser
15	synstructure	@mystor	Apache-2.0/MIT	`syn` structure macros
16	thiserror	@dtolnay	Apache-2.0/MIT	`Error` custom derive
17	tracing-attributes	tokio-rs	MIT	App tracing / logging
18	unicode-xid	unicode-rs	Apache-2.0/MIT	Identify valid Unicode
19	wait-timeout	@alexcrichton	Apache-2.0/MIT	Timeouts for waitpid

Dependency Relationships

The table below should help answer questions as to why a particular crate is an Abscissa dependency and whether or not it is optional. Abscissa uses cargo features to allow parts of it you aren't using to be easily disabled, so you only compile the parts you need.

Crate Name	Cargo Features	Required By
abscissa_core	-	⊤
abscissa_derive	-	abscissa_core
aho-corasick	`trace`, `testing`	regex
ansi_term	`trace`	tracing-subscriber
arc-swap	`signals`	signal-hook-registry
atty	`terminal`	color-backtrace
autocfg	`time`	num-integer
backtrace	-	abscissa_core
backtrace-sys	-	backtrace
byteorder	`trace`	regex-automata
canonical-path	-	abscissa_core
cc	-	backtrace-sys
cfg-if	-	backtrace, log
color-backtrace	`terminal`	abscissa_core
chrono	`time`	abscissa_core
darling	-	abscissa_derive
darling_core	-	darling, darling_macro
darling_macro	-	darling
fs-err	-	abscissa_core
fnv	-	darling_core
generational-arena	`application`	abscissa_core
gumdrop	`options`	abscissa_core
gumdrop_derive	`options`	gumdrop
ident_case	-	abscissa_derive, darling_core
lazy_static	`testing`, `trace`	thread_local, tracing-core, tracing-log, tracing-subscriber
libc	`signals`	abscissa_core
log	`logging`	abscissa_core
matchers	`trace`	tracing-subscriber
memchr	`trace`, `testing`	aho-corasick
maybe-uninit	`trace`	smallvec
num-integer	`time`	chrono
num-traits	`time`	chrono, num-integer
once_cell	-	abscissa_core
proc-macro2	-	abscissa_derive, darling, quote, serde_derive, syn
quote	-	abscissa_derive, darling, gumdrop_derive, serde_derive
redox_syscall	`time`	time
regex	`trace`, `testing`	abscissa_core
regex-automata	`trace`	matchers
regex-syntax	`trace`, `testing`	abscissa_core
rustc-demangle	-	backtrace
secrecy	`secrets`	abscissa_core
semver	`application`	abscissa_core
semver-parser	`application`	abscissa_core
serde	`config`	abscissa_core
serde_derive	`config`	serde
signal-hook	`signals`	abscissa_core
sharded-slab	`trace`	tracing-subscriber
signal-hook-registry	`signals`	signal-hook
smallvec	`trace`	tracing-subscriber
strsim	-	darling_core
syn	-	abscissa_derive, darling, gumdrop_derive, serde_derive
termcolor	`terminal`	abscissa_core
thiserror	-	Abscissa boilerplate
thread_local	`trace`, `testing`	regex
time	`logging`	chrono
tracing	`trace`	abscissa_core
tracing-attributes	`trace`	tracing
tracing-core	`trace`	tracing
tracing-log	`trace`	abscissa_core
tracing-subscriber	`trace`	abscissa_core
unicode-xid	-	proc-macro2, syn
utf8-ranges	`trace`, `testing`	regex
wait-timeout	`testing`	abscissa_core
winapi§	-	termcolor, time, winapi-util
winapi-util	-	termcolor
wincolor	`terminal`	termcolor
zeroize	-	abscissa_core

§ winapi is a facade for either winapi-i686-pc-windows-gnu or winapi-x86_64-pc-windows-gnu which aren't explicitly listed for brevity and are only required on Windows platforms.

Frequently Asked Questions (FAQ)

Q1: Why is it called "abscissa"?

A1: The word "abscissa" is the key to the Kryptos K2 panel.

Q2: "Abscissa" is a hard name to remember! Got any tips?

A2: Imagine you're A-B testing a couple of scissors... with attitude.

Testing Framework Changes

The main way to test framework changes is by generating an application with Abscissa's built-in application generator and running tests against the generated application (also rustfmt, clippy).

To generate a test application and test it automatically, you can simply do:

$ cargo test

However, when debugging test failures against a generated app, it's helpful to know how to drive the app generation and testing process manually. Below are instructions on how to do so.

If you've already run:

$ git clone https://github.com/iqlusioninc/abscissa/

...and are inside the abscissa directory and want to test your changes, you can generate an application by running the following command:

$ cargo run -- new /tmp/example_app --patch-crates-io='abscissa = { path = "$PWD" }'

This will generate a new Abscissa application in /tmp/example_app which references your local copy of Abscissa.

After that, change directory to the newly generated app and run the tests to ensure things are still working (the tests, along with rustfmt and clippy are run as part of the CI process):

$ cd /tmp/example_app # or 'pushd /tmp/example_app' and 'popd' to return
$ cargo test
$ cargo fmt -- --check # generated app is expected to pass rustfmt
$ cargo clippy

Code of Conduct

We abide by the Contributor Covenant and ask that you do as well.

For more information, please see CODE_OF_CONDUCT.md.

License

The abscissa crate is distributed under the terms of the Apache License (Version 2.0).

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

https://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software 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.

Contribution

If you are interested in contributing to this repository, please make sure to read the CONTRIBUTING.md and CODE_OF_CONDUCT.md files first.

Comments

Migrate from `log` to `tracing`
Hi, in Zebra https://github.com/ZcashFoundation/zebra we used @hawkw's tracing rather than log and wrote our own TracingComponent.

Would Abscissa be interested in upstreaming (a modified version of) that component and replacing the default log component with a tracing-based one? In contrast to log, tracing is much more async-friendly, but can remain compatible with log-based crates.

There are some design questions, if this turns out to be of interest to Abscissa:

One of the really killer features of tracing is dynamic filter reloading -- how should this be exposed to Abscissa applications?

In Zebra, we have an HTTP endpoint that allows feeding inputs to the filter reloading. Should Abscissa provide a default mechanism for doing filter reloading? My guess is no, that this is application-specific (e.g., we will probably fold ours into the standard RPC interface).
opened by hdevalence 14
crates: Replacements for failure?
std::error::Error now contains a trait as expressive as the Fail trait from failure, including downcast support and downcastable Error::source as a replacement for Error::cause (now with a 'static lifetime bound).

Additionally, there are a number of custom derive crates for std::error::Error now available:

err-derive

snafu

thiserror

Given that, it seems like we can eliminate failure as a dependency, potentially replacing failure_derive with one of the crates above.

Serializable Errors

A bit of a sidebar, but one of the things I'd like to eventually accomplish is serde support for the framework's Error type, making it Serialize-able (and ideally Deserialize-able as well), with the intent of serializing them as JSON for reporting to an exception reporting service.

The backtrace crate offers serde support as an optional feature, however accessing this functionality was previously difficult as Abscissa's Error type uses failure::Context to capture and store backtraces. It seems like Abscissa could benefit from providing a similar Context type as a replacement for the one failure provided. Ideally this type could simply derive(Serialize, Deserialize), permitting straightforward serialization of errors as well as their backtraces (and ideally, the entire error chain).

Unfortunately the story around all of this is complicated by adding a Backtrace type to std, presently only available on nightly. This Backtrace type has deliberately minimal functionality.

I'd consider supporting Backtrace on stable a requirement, and ideally preserving the serde serialization support. This seems possible with snafu but needs more investigation.

Crates like err-derive and thiserror have the advantage of being pure proc macros with no additional API dependencies, so if nothing else they stay nicely out of the way and orthogonal to this problem. I imagine if we don't go with snafu, we could pick one of these to be the out-of-the-box custom derive for errors, but with the only framework-level association being inclusion in the default application template (allowing downstream users of the users to potentially remove it or swap it out if they so desire)
question dependency
opened by tarcieri 10
Refactor the logging component to a tracing component.
Will resolve #149 when complete.

Some questions:

How do I determine whether ANSI should be used?

Should the tracing settings respect RUST_LOG?

I didn't update the crate list in the README.
opened by hdevalence 9

Component registry never registers components - component registry doesn't work.

https://github.com/iqlusioninc/abscissa/blob/710e10618d75b3aaa796ad5f5f96c9531fc0171c/core/src/component/registry.rs#L35

It seems that the register function goes through all the motions of registering a new set of components, but never actually mutates the registry to insert them. Is this a known issue, not implemented yet, or am I using the registry wrong?

This breaks the ability to use registered components in applications. In generated application.rs for example:

/// Register all components used by this application.
///
/// If you would like to add additional components to your application
/// beyond the default ones provided by the framework, this is the place
/// to do so.
fn register_components(&mut self, command: &Self::Cmd) -> Result<(), FrameworkError> {
    let mut components = self.framework_components(command)?;
    // expect the application's components register to contain:
    // abscissa_core::terminal
    // abscissa_core::logging
    self.state.components.register(components)?;

    // No components are found :(
    for component in self.state.components.iter() {
        println!("registered component: {}", component.name())
    }
    Ok(())
}

opened by lberezy 9

Need help writing tests

I have lots of logging in my application code which is helpful when doing cargo run, but cargo test doesn't have any initialization for config or logging.

Right now, I use println! in my test code, but I'd like to see some of the debug logs from the application code, too.

I also want to test some functions that have calls to app_config(), but right now they fail with an error about config not being initialized.

How should I setup config and logging without running boot in my tests?

opened by WyseNynja 8
update `tracing-subscriber` to 0.2.0

This branch updates the tracing-subscriber dependency to version 0.2.0. This is a major release which includes a couple of important bug fixes; in particular, we've fixed a memory leak caused by spans failing to close their parents, and made significant improvements to performance under high concurrency.

Since this is also a potentially breaking change, I'm trying to help some of our major dependents update by opening PRs against projects that use tracing-subscriber. However, it looks like Abscissa didn't actually use any of the APIs we broke in this release :)

Additionally, while I'm here, I took the liberty of updating the dependency list in the README to reflect changes in transitive dependencies pulled in by tracing-subscriber and tracing. Several dependencies were removed — in particular, the dependency on spin — and a couple were added, but I'm happy to note that the tracing update has a net-negative impact on Abscissa's total number of dependencies. Hopefully this is helpful!

opened by hawkw 7
Question: Logging target
As a followup to "Damonizing and encrypting with Abscissa"..

Since I will be running as a daemon, I need to change some logging options:

redirect all logging activity to file

Change output formatting (Time format, add threads etc) Is there a way to do that? I've been digging but don't see a way short of modifying "application" and "trace/component"...

Thanks JR
opened by JRAndreassen 6
tokio: Initial `abscissa_tokio` crate

Adds an abscissa_tokio crate containing a TokioComponent which manages the lifecycle for spawning a tokio::runtime::Runtime.

Inspired by the approach used in Zebrad:

https://github.com/ZcashFoundation/zebra/blob/4fcb550/zebrad/src/components/tokio.rs

cc @hdevalence @dconnolly

opened by tony-iqlusion 5
Port to clap v3

This is a reasonably straightforward port of Abscissa to Clap v3 using the custom derives. I removed most of the command subsystem (EntryPoint, Usage, Help) since Clap takes over most of those roles.

To demonstrate how this could work, I also migrated the CLI.

The ergonomics might be improved, as subcommands work differently in Clap than Gumdrop. This is best seen in the commands.rs file of the CLI and gen.rs root command. Embedding subcommands can get tedious quickly.

Another gotcha I found is that #[derive(Runnable)] will not work for structs in its current form, so a manual implementation is necessary.

If this changeset looks like a viable approach, I can take a look at porting the template.

Resolves #298

opened by rsdy 4
Replace gumdrop with clap v3 (beta 1)
closes: #298

I've started the work to try to replace gumdrop with clap v3.

Mostly replace dependencies in Cargo.toml files. Replaced gumdrop (0.7) with clap (3.0.0-beta.1)

Replaced attributes that used gumdrop #[option(... with #[clap... since clap supports this with clap_derive

Replaced some gumdrop Error with clap Error

After replacing these, got stuck on core/src/command/entrypoint.rs where the compilation is failing because changes in the file. Especially the command property of this struct. Couldn't find an equivalent way to replace it with clap. Tried to use the #[clap(subcommand)] attribute on this property but it seems make the compiler not to recognize the Cmd type

error[E0412]: cannot find type `Cmd` in this scope --> core/src/command/entrypoint.rs:33:25 | 33 | pub command: Option<Cmd>, | ^^^ not found in this scope

So I believe this is a good starting point but I believe some more fundamental changes will be required in order to replace gumdrop with clap. Especially things related to help and usage which clap supports. So maybe things that currently exist in abscissa like core/src/command -> entrypoint, help and usage might not need to exist or be refactored quite a bit.

Another challenge is that clap also has a concept of App but it's more related to command line arguments and the executable, so it might differ from Abscissa's CliApplication that can track the State.

Anyways, I think we can use this draft PR to have discussions on what is the best way to proceed and I'd be happy to help out with this effort.
opened by andynog 4
Tokio usage: abscissa_tokio::run... take_runtime() stuck in app.write()
I have a Tokio usage question, it may be my understanding of your sequence of events , but I have not been able to determine it from the docs...

I have a set of sub-modules / commands that are dependent upon Tokio runtime. They get called to perform a specific sub-task then return. According to the doc's, Include abscissa_tokio and call run.. I added: components.push(Box::new(TokioComponent::new()?)); then call

impl Runnable for XXXCmd { fn run(&self) { let config = app_config(); let _ = abscissa_tokio::run(&APPLICATION, async{ println!("Started {}", "Junk"); } );

Whcih calls tokio::block_on... Which is essentially what tokio::main does. So, the runtime is initialized, I see all the threads in the debugger, but the app is stuck at (partial stack) app.write TokioComponent::take_runtime TokioComponent::run Waiting for the write lock...

In my case, I have no other component's / services running. So I just need Tokio runtime initialized and available, the terminate after the run is done.

What am I missing...

Any insight would be greatly appreciated...
opened by JRAndreassen 4
build(deps): bump tokio from 1.21.2 to 1.23.1
Bumps tokio from 1.21.2 to 1.23.1.

Release notes

Sourced from tokio's releases.

Tokio v1.23.1

This release forward ports changes from 1.18.4.

Fixed

net: fix Windows named pipe server builder to maintain option when toggling pipe mode (#5336).

#5336: tokio-rs/tokio#5336

Tokio v1.23.0

Fixed

net: fix Windows named pipe connect (#5208)

io: support vectored writes for ChildStdin (#5216)

io: fix async fn ready() false positive for OS-specific events (#5231)

Changed

runtime: yield_now defers task until after driver poll (#5223)

runtime: reduce amount of codegen needed per spawned task (#5213)

windows: replace winapi dependency with windows-sys (#5204)

#5208: tokio-rs/tokio#5208 #5216: tokio-rs/tokio#5216 #5213: tokio-rs/tokio#5213 #5204: tokio-rs/tokio#5204 #5223: tokio-rs/tokio#5223 #5231: tokio-rs/tokio#5231

Tokio v1.22.0

Added

runtime: add Handle::runtime_flavor (#5138)

sync: add Mutex::blocking_lock_owned (#5130)

sync: add Semaphore::MAX_PERMITS (#5144)

sync: add merge() to semaphore permits (#4948)

sync: add mpsc::WeakUnboundedSender (#5189)

Added (unstable)

process: add Command::process_group (#5114)

runtime: export metrics about the blocking thread pool (#5161)

task: add task::id() and task::try_id() (#5171)

Fixed

macros: don't take ownership of futures in macros (#5087)

runtime: fix Stacked Borrows violation in LocalOwnedTasks (#5099)

runtime: mitigate ABA with 32-bit queue indices when possible (#5042)

task: wake local tasks to the local queue when woken by the same thread (#5095)

time: panic in release mode when mark_pending called illegally (#5093)

runtime: fix typo in expect message (#5169)

... (truncated)

Commits

1a997ff chore: prepare Tokio v1.23.1 release

a8fe333 Merge branch 'tokio-1.20.x' into tokio-1.23.x

ba81945 chore: prepare Tokio 1.20.3 release

763bdc9 ci: run WASI tasks using latest Rust

9f98535 Merge remote-tracking branch 'origin/tokio-1.18.x' into fix-named-pipes-1.20

9241c3e chore: prepare Tokio v1.18.4 release

699573d net: fix named pipes server configuration builder

3ce5a26 chore: prepare Tokio v1.23 release (#5270)

644cb82 rt: fix *_closed false positives (#5231)

a1316cd io: impl std::io::BufRead on SyncIoBridge\<T> (#5265)

Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

@dependabot rebase will rebase this PR

@dependabot recreate will recreate this PR, overwriting any edits that have been made to it

@dependabot merge will merge this PR after your CI passes on it

@dependabot squash and merge will squash and merge this PR after your CI passes on it

@dependabot cancel merge will cancel a previously requested merge and block automerging

@dependabot reopen will reopen this PR if it is closed

@dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually

@dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)

@dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)

@dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

dependency
opened by dependabot[bot] 0
build(deps): bump once_cell from 1.16.0 to 1.17.0
Bumps once_cell from 1.16.0 to 1.17.0.

Changelog

Sourced from once_cell's changelog.

1.17.0

Add race::OnceRef for storing a &'a T.

Commits

85e372f Merge #213

fae9f73 Add once_cell::race::OnceRef

0d0dae1 Merge #212

e94003a Removed Debug impls to de-clutter example

3f750e1 Fixed LateInit example stack overflow

ba8b9fe Merge #209

ea438d8 Merge #210

f68835a fix miri tests

6d46f40 Add references to generic_once_cell

47bf9ae Readme: Sync related crates to docs

See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

@dependabot rebase will rebase this PR

@dependabot recreate will recreate this PR, overwriting any edits that have been made to it

@dependabot merge will merge this PR after your CI passes on it

@dependabot squash and merge will squash and merge this PR after your CI passes on it

@dependabot cancel merge will cancel a previously requested merge and block automerging

@dependabot reopen will reopen this PR if it is closed

@dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually

@dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)

@dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)

@dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

dependency
opened by dependabot[bot] 0
build(deps): bump clap from 4.0.19 to 4.0.32
Bumps clap from 4.0.19 to 4.0.32.

Release notes

Sourced from clap's releases.

v4.0.32

[4.0.32] - 2022-12-22

Fixes

(parser) When overriding required(true), consider args that conflict with its group

v4.0.31

[4.0.31] - 2022-12-22

Performance

Speed up parsing when a lot of different flags are present (100 unique flags)

v4.0.30

[4.0.30] - 2022-12-21

Fixes

(error) Improve error for args_conflicts_with_subcommand

v4.0.29

[4.0.29] - 2022-11-29

v4.0.28

[4.0.28] - 2022-11-29

Fixes

Fix wasm support which was broken in 4.0.27

v4.0.26

[4.0.26] - 2022-11-16

Fixes

(error) Fix typos in ContextKind::as_str

v4.0.25

[4.0.25] - 2022-11-15

Features

(error) Report available subcommands when required subcommand is missing

v4.0.24

[4.0.24] - 2022-11-14

Fixes

... (truncated)

Changelog

Sourced from clap's changelog.

[4.0.32] - 2022-12-22

Fixes

(parser) When overriding required(true), consider args that conflict with its group

[4.0.31] - 2022-12-22

Performance

Speed up parsing when a lot of different flags are present (100 unique flags)

[4.0.30] - 2022-12-21

Fixes

(error) Improve error for args_conflicts_with_subcommand

[4.0.29] - 2022-11-29

[4.0.28] - 2022-11-29

Fixes

Fix wasm support which was broken in 4.0.27

[4.0.27] - 2022-11-24

Features

Have Arg::value_parser accept Vec<impl Into<PossibleValue>>

Implement Display and FromStr for ColorChoice

Fixes

Remove soundness issue by switching from atty to is-terminal

[4.0.26] - 2022-11-16

Fixes

(error) Fix typos in ContextKind::as_str

[4.0.25] - 2022-11-15

Features

(error) Report available subcommands when required subcommand is missing

[4.0.24] - 2022-11-14

... (truncated)

Commits

ec4ccf0 chore: Release

13fdb83 docs: Update changelog

b877345 Merge pull request #4573 from epage/conflict

85ecb3e fix(parser): Override required when parent group has conflict

d145b8b test(parser): Demonstrate required-overload bug

0eccd55 chore: Release

1e37c25 docs: Update changelog

dcd5fec Merge pull request #4572 from epage/group

dde22e7 style: Update for latest clippy

dd8435d perf(parser): Reduce duplicate lookups

Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

@dependabot rebase will rebase this PR

@dependabot recreate will recreate this PR, overwriting any edits that have been made to it

@dependabot merge will merge this PR after your CI passes on it

@dependabot squash and merge will squash and merge this PR after your CI passes on it

@dependabot cancel merge will cancel a previously requested merge and block automerging

@dependabot reopen will reopen this PR if it is closed

@dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually

@dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)

@dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)

@dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

dependency
opened by dependabot[bot] 0
build(deps): bump handlebars from 4.3.5 to 4.3.6
Bumps handlebars from 4.3.5 to 4.3.6.

Changelog

Sourced from handlebars's changelog.

4.3.6 - 2022-12-21

[Fixed] Loading template files with multiple extensions, a bug introduced in 4.3.0 when refactoring directory source.

Commits

0470ce7 chore: Release handlebars version 4.3.6

5148dea chore: update release.toml for new cargo-release

fbd812f docs: update changelog

40ecb11 fix: loading templates which has multiple extensions

9a8335c (cargo-release) start next development iteration 4.3.6-alpha.0

See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

@dependabot rebase will rebase this PR

@dependabot recreate will recreate this PR, overwriting any edits that have been made to it

@dependabot merge will merge this PR after your CI passes on it

@dependabot squash and merge will squash and merge this PR after your CI passes on it

@dependabot cancel merge will cancel a previously requested merge and block automerging

@dependabot reopen will reopen this PR if it is closed

@dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually

@dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)

@dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)

@dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

dependency
opened by dependabot[bot] 0
build(deps): bump quote from 1.0.21 to 1.0.23
Bumps quote from 1.0.21 to 1.0.23.

Release notes

Sourced from quote's releases.

1.0.22

Documentation improvements

Commits

550af67 Release 1.0.23

b0337d0 Opt out -Zrustdoc-scrape-examples on docs.rs

2386c5a Release 1.0.22

ead304a Update build status badge

51d3bd2 Update ui test suite to nightly-2022-12-15

2922a8e Time out workflows after 45 minutes

6f42f3c Fix renamed let_underscore_drop lint

b2e30cc MIT copyright line

efc9b69 Ui test changes for trybuild 1.0.66

1e2b198 Raise minimum tested toolchain to rust 1.56

Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

@dependabot rebase will rebase this PR

@dependabot recreate will recreate this PR, overwriting any edits that have been made to it

@dependabot merge will merge this PR after your CI passes on it

@dependabot squash and merge will squash and merge this PR after your CI passes on it

@dependabot cancel merge will cancel a previously requested merge and block automerging

@dependabot reopen will reopen this PR if it is closed

@dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually

@dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)

@dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)

@dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

dependency
opened by dependabot[bot] 0
build(deps): bump proc-macro2 from 1.0.47 to 1.0.49
Bumps proc-macro2 from 1.0.47 to 1.0.49.

Release notes

Sourced from proc-macro2's releases.

1.0.48

Documentation improvements

Commits

293705d Release 1.0.49

6b9ee3d Opt out -Zrustdoc-scrape-examples on docs.rs

a83ad60 Release 1.0.48

b4fa77f Update build status badge

975c324 Time out workflows after 45 minutes

f633e31 MIT copyright line

See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

@dependabot rebase will rebase this PR

@dependabot recreate will recreate this PR, overwriting any edits that have been made to it

@dependabot merge will merge this PR after your CI passes on it

@dependabot squash and merge will squash and merge this PR after your CI passes on it

@dependabot cancel merge will cancel a previously requested merge and block automerging

@dependabot reopen will reopen this PR if it is closed

@dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually

@dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)

@dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)

@dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

dependency
opened by dependabot[bot] 0