Fix documenting with undocumented dependencies.
#10201 introduced a bug where dependencies that have `doc=false` weren't being built at all when running `cargo doc` if the project did not have any binaries. That means the rmeta file was missing, and the `--extern` flag was not being passed to rustdoc.
The solution is to ensure the `rmeta` file gets generated, but only skip generating the `CompileMode::Doc` unit for undocumented dependencies.
This unblocks the bootstrap bump.
do not compile test for bins flagged as `test = false`
### What does this PR try to resolve?
Fixes#10268#6683 introduced a behavior that compiles all bin targets, but for bins with `test = false` they shouldn't be compiled with `--test` as testbins.
### How should we test and review this PR?
In the first commit of this PR, I refines the test `test_filtered_excludes_compiling_examples` to reflect the current wrong behavior (test passed). The following two commits correct the behavior and the test accordingly. The last few commits encapsulate scattered target selection logic into functions on `CompileFilter`.
Port cargo from toml-rs to toml_edit
Benefits:
- A TOML 1.0 compliant parser
- Unblock future work
- Have `cargo init` add the current crate to the workspace, rather
than error
- #5586: Upstream `cargo-add`
TODO
- [x] Analyze performance and address regressions
- [x] Identify and resolve incompatibiies
- [x] Resolve remaining test failures, see
https://github.com/ordian/toml_edit/labels/cargo
- [x] ~~Switch the code from https://github.com/rust-lang/cargo/pull/10176 to only parse once~~ (this PR is being merged first)
Fix new::git_default_branch with different default
The test `new::git_default_branch` would fail if the current user had already configured a different default branch.
This patch changes the test to first write a `.gitconfig` file with the default branch set to master. This puts us in a state where we still have the old default, and then the subsequent change to the config file will make sure that config changes are still respected.
The test new::git_default_branch would fail if the current user had
already configured a different default branch.
This patch changes the test to first write a .gitconfig file with the
default branch set to master. This puts us in a state where we still
have the old default, and then the subsequent change to the config file
will make sure that config changes are still respected.
Error when setting crate type of both dylib and cdylib in library
close https://github.com/rust-lang/cargo/issues/10231
Error when setting crate type of both dylib and cdylib in library. Cargo can't support that at this time, since they both output the same filename.
Include `help` in `--list`
This adds the `help` subcommand to the `--list` output. It previously was not included because `help` is handled differently from built-in subcommands.
Downgrade some log messages.
This lowers the log level of several "info" messages. I find that these can be quite noisy when using log messages, and I don't think need to be such a high log level.
Enable shortcut for triage bot
### What does this PR try to resolve?
Enable shortcut for triage bot. See: https://github.com/rust-lang/cargo/pull/10167#issuecomment-1013815453
### How should we test and review this PR?
We need to test it after the merge. But there should be no problem with the robot. I refer to the rust configuration file.
### Additional information
I don't know if it is accepted to open it, if we don't want to open it please feel free to close my PR.
use new cargo fmt option
As of v1.58, cargo fmt now supports the --check flag directly. Updating it here (and in a few other r-l repos) both because it's more succinct and so more people will see/become aware
Add `run-fail` to semver-check for docs
I encountered this missing feature in #10276 and therefore added it here in this separate PR.
If the breaking change does not involve a compilation error but a change in runtime behaviour, you can add `run-fail` to the codeblock. The "before" code must return exit code 0, and the "after" code must be nonzero (like a panic).
Example case that I tested (ignore the trailing dot, it's for github markdown to not hate me)
```
```rust,ignore,run-fail
// MAJOR CHANGE
///////////////////////////////////////////////////////////
// Before
pub fn foo() {}
///////////////////////////////////////////////////////////
// After
pub fn foo() {
panic!("hey!");
}
///////////////////////////////////////////////////////////
// Example usage that will break.
fn main() {
updated_crate::foo();
}
```.
```
Use `is_symlink()` method
I've came across this comment
```rust
// Replace with std implementation when stabilized, see
// https://github.com/rust-lang/rust/issues/85748
```
and fixed this due to the method stabilization in 1.58
Benefits:
- A TOML 1.0 compliant parser
- Unblock future work
- Have `cargo init` add the current crate to the workspace, rather
than error
- #5586: Upstream `cargo-add`
if the breaking change does not involve a compilation error but a change in runtime behaviour, you can add `run-fail` to the codeblock. The "before" code must return exit code 0, and the "after" code must be nonzero (like a panic).
Stabilize namespaced and weak dependency features.
This stabilizes the namespaced and weak dependency features. Support is now enabled on crates.io, so this should be ready to go.
As a part of this change, the new feature resolver is now enabled all of the time. This is fairly risky, since there are likely edge cases that haven't been exercised.
NOTE: Projects using `resolver="1"` *should* continue to have the same behavior, the old resolver behavior is emulated.
Closes#8813Closes#8832
Port cargo to clap3
### What does this PR try to resolve?
This moves cargo to the latest major version of clap.
This supersedes #10259 and #10262
### How should we test and review this PR?
For testing, I mostly relied on existing tests. I did manually validate that `cargo run <non-escaped command args>` behaved the same between both
```console
$ cargo run release --help
Finished dev [unoptimized + debuginfo] target(s) in 0.22s
Running `target/debug/cargo-release release --help`
cargo-release 0.18.8
...
$ cargo run --manifest-path ../cargo/Cargo.toml -- run release --help
Finished dev [unoptimized + debuginfo] target(s) in 0.05s
Running `/home/epage/src/personal/cargo/target/debug/cargo run release --help`
Finished dev [unoptimized + debuginfo] target(s) in 1.31s
Running `target/debug/cargo-release release --help`
cargo-release 0.18.8
...
```
For reviewing, I split out each deprecation resolution into a separate commit so its easy to focus on more mechanical changes (most of the deprecation fixes) from interesting ones (the port, the `Arg::multiple` deprecation)
### Additional information
- One parser change found by `cargo_config::includes` is that clap 2
would ignore any values after a `=` for flags.
`cargo config --show-origin` is a flag but the test passed `--show-origin=yes` which
happens to give the desired result for that test but is the same as
`--show-origin=no` or `--show-origin=alien-invasion`.
- `ArgMatches` now panics when accessing an undefined argument but clap
takes advantage of that for sharing code across commands that have
different subsets of arguments defined. I've extended clap so we can
"look before you leap" and put the checks at the argument calls to
start off with so its very clear what is tenuously shared. This
allows us to go in either direction in the future, either addressing
how we are sharing between commands or by moving this down into the
extension methods and pretending this clap feature doesn't exist
- On that topic, a test found clap-rs/clap#3263. For now, there is a
hack in clap. Depending on how we fix that in clap for clap 4.0, we
might need to re-address things in cargo.
- `value_of_os` now requires setting `allow_invalid_utf8`, otherwise it
asserts. To help catch this, I updated the argument definitions
associated with lookups reported by:
- `rg 'values?_os' src/`
- `rg 'values?_of_os' src/`
- clap now reports `2` for usage errors, so we had to bypass clap's
`exit` call to keep the same exit code.
- `cargo vendor --sync` did not use `multi_opt` and so it has both
multiple occurrences **and** multiple values. If we want to deprecate
this, we'll need `unstable-grouped` to be stablized (or pin our clap
version) and ensure each group has only 1 value.
Note: `cargo vendor --sync` did not use `multi_opt` and so it has both
multiple occurrences **and** multiple values. If we want to deprecate
this, we'll need `unstable-grouped` to be stablized (or pin our clap
version) and ensure each group has only 1 value.
