I want to run tests with release optimisations using 1 test thread.
I can do these individually:
cargo test -- --test-threads=1
cargo test --release
How would I put these together?
You can use both in a single command like this:
cargo test --release -- --test-threads=1
How Cargo interprets these arguments ?
According to test subcommand's synopsis in reference :
cargo test [OPTIONS] [TESTNAME] [-- TEST-OPTIONS]
Cargo interprets input as :
Arguments before separator (--) will be used as an option for test subcommand. In your case cargo test accepts profile parameter as an option since it builds the project. Available options can be found under this title, or by running cargo test --help.
Arguments after the separator will be passed to the test binaries. In Rust project, Cargo uses rustc's libtest to run unit tests. In your case --test-threads=1 will be an argument for libtest.
This interpretation might not be valid for other subcommands, it is best to check other cargo commands from here. Checking synopsis section will give you a huge hint about capabilities of cargo's subcommands.
See also:
Since arguments after the dash will be sent to the rustc's libtest you can see available options for testing by: cargo test -- --help.
Profile options can be found under this title
Related
A fantastic crate is cargo watch, which allows, for example, for you to execute:
cargo watch -x run
to automatically rebuild/run on src change. This is amazing for development but one issue I have is that it seems to not support the --manifest-path argument that can be used with cargo run to explicitly specify the path to the .toml file of the project such that it can be run from a different pwd than the Cargo.toml file itself:
cargo run --manifest-path /home/user/project/Cargo.toml
The crate documentation doesn't mention anything about this, so I was wondering if anyone who uses this crate has found a way around this. When attempting to use the --manifest-path argument I receive:
error: Found argument '--manifest-path' which wasn't expected, or isn't valid in this context
USAGE:
cargo watch [FLAGS] [OPTIONS]
Which makes some sense as I know not all commands support the --manifest-path arg, but since the crate uses cargo run to run the project itself I'm guessing there is some way around this without using e.g. sh -c 'cd [path to .toml file] && cargo watch -x run'
Yes you can just use the invocation which lets you run arbitrary commands:
cargo watch -- cargo run --manifest-path=path/to/Cargo.toml
According to doc.rust-lang.org
cargo rustdoc
build[s] a package's documentation, using specified custom flags
cargo doc
build[s] a package's documentation
What is the difference between the two? From what I understand cargo rustdoc is just like cargo doc, but it allows for more lints—for instance:
#![deny(rustdoc::broken_intra_doc_links)]
Is this correct? Oddly enough, cargo rustdoc will also fail in certain situations where cargo doc doesn't. For instance
some/folder on some-branch [$!] via 🦀 v1.60.0-nightly
❯ cargo doc
Finished dev [unoptimized + debuginfo] target(s) in 0.53s
some/folder on some-branch [$!] via 🦀 v1.60.0-nightly
❯ cargo rustdoc
error: manifest path `some/folder/Cargo.toml` is a virtual manifest, but this command requires running against an actual package in this workspace
Also, cargo doc does not support adding the -D option, whereas cargo rustdoc does.
❯ cargo doc -- -D rustdoc::broken_intra_doc_links
error: Found argument '-D' which wasn't expected, or isn't valid in this context
USAGE:
cargo doc [OPTIONS]
For more information try --help
Their relationship is like between cargo build and cargo rustc: cargo doc performs all the usual work, for an entire workspace, including dependencies (by default). cargo rustdoc allows you to pass flags directly to rustdoc, and only works for a single crate.
Here is the execution code for cargo rustdoc. Here is the code for cargo doc. The only differences is that cargo rustdoc always specify to not check dependencies while cargo doc allows you to choose (by default it does, but you can specify the flag --no-deps), and that cargo rustc allows you to pass flags directly to rustdoc with the flags after the --.
I'm implementing a custom Cargo subcommand that mostly runs cargo build followed by some processing on a successful invocation. Cargo itself supports several ways to customize defaults, (e.g. the --target selected when omitted), which this subcommand exposes as well.
The challenge now is to find the defaults that cargo build uses from the subcommand implementation. With build scripts getting access to all sorts of information, this isn't the case for subcommands. Running cargo metadata doesn't seem to produce that information either (such as the TARGET).
Is there any way to query Cargo about the configuration it will be using for a cargo build invocation, and make that available to a Cargo custom subcommand?
I got a problem by using this command cargo -- build --features ffi, and the built library does not contain symbols I want.
I debugged a whole day and finally found that cargo build --features ffi (no -- before build) will work.
I searched for a while and didn't find what is the usage of a single --, so any help on when it is used and what's the different with or without this --?
As #Sergio already point out, the double dash (--) is commonly indicates the end of options argument after which only positional arguments may follow (also see this answer for more details).
In this particular case, the double dash between cargo and build seems quite buggy as it behaviors inconsistently:
# Intended behavior, `--features ffi` is an option
cargo build --features ffi --
# Fails because no positional arguments are expected
cargo build -- --features ffi
# Silently ignores the positional `--features ffi`
cargo -- build --features ffi
However, thanks to #Inline's bug fix, we should expect this pit-fall to become an issue of the past.
I'm working on a project split across multiple crates. The top-level crate (the app) requires the two other crates (libraries) as dependencies. Running cargo test in the top-level crate builds the dependencies and runs tests for the top-level crate, but it doesn't run tests for the two other crates. Is there a way to configure cargo test so that it will run tests in all three crates?
Thanks!
You can pass the -p parameter to make Cargo run the tests of a dependency.
So, if your crate is called sublib, you can run its tests using:
cargo test -p sublib
From cargo test --help:
-p SPEC, --package SPEC Package to run tests for
If the --package argument is given, then SPEC is a package id
specification which indicates which package should be tested. If it is
not given, then the current package is tested. For more information on
SPEC and its format, see the cargo help pkgid command.