### What does this PR try to resolve?
`CFG_VER_DESCRIPTION` is descriptive string to be appended to version
output.
This is usually set by the bootstrap in rust-lang/rust. Useful for
showing vendor build information.
See <https://github.com/rust-lang/rust/pull/137723>.
### How should we test and review this PR?
```bash
CFG_VER_DESCRIPTION="My Awesome Rust Distribution" cargo b
target/debug/cargo version
```
`CFG_VER_DESCRIPTION` is descriptive string to be
appended to version output.
This is usually set by the bootstrap in rust-lang/rust.
Useful for showing vendor build information.
See <https://github.com/rust-lang/rust/pull/137723>.
This update makes the stable hasher consistent across endianness, fixing
cargo's `test_stable_hash` on big-endian targets to match the
little-endian expected values.
Fixes#15265
### What does this PR try to resolve?
Fixes#15239
This also makes `--frozen` be respected in more situations, including
* `cargo add`
* `cargo install`
* Git fetches
* HTTP registry access
### How should we test and review this PR?
To prevent this from happening again, I removed `offline()` and
`locked()` accessors. To maintain the quality of error messages, I added
`offline_flag()` and `locked_flag()` that will pick up `--frozen`, if
present.
### Additional information
### What does this PR try to resolve?
This is an experiment to find ways to make `cargo tree` output easier to
grok. I find too many details are hard to spot because everything looks
the same.
The goal is to make it easier to scan the output for relevant details.
So far, this approach seems the most viable. Knowing what type of edges
led to where you are provides useful context for scrolling through large
lists of dependencies.
Fixes#10558
### How should we test and review this PR?
I had considered styling normal dependency edges but there isn't a
header to clarify what they mean, so I decided to match the package name
as that is the header. So this didn't buy as much as I had hoped,
especially since dimmed lines aren't obvious with my terminal. Maybe if
we used different unicode graph characters.
Instead of coloring the "this is elided" `(*)`, I had considered using a
unicode character that looks like its pointing from that item up. I only
found one that looked close to that but the origin for the arrow was
bottom aligned, rather than center aligned and it looked off.
Alternatives considered
- Once an edge is marked with dev or build dependencies, all future
edges inherit it
- While this makes it clear what section you are in, so does the outer
most line
- Feature edges are the color of the edges that led to them
- Unsure of value either way
- This might get weird with `--invert`
- Style local nodes different than non-local
- With the format string being user customizable, I'm concerned with
styling over or within user styling
- Rainbow packages: For every package in the same namespace
(`.split_once("::").0`) or prefix (`.split_once(['-','_']).0`), assign a
color (maybe only for the top N packages to reduce duplicate colors)
- Would help a lot with `gix-*` and similar other cases
- If we cap the number of participating packages, would need care to
work with `--depth`
(of course,. these could be mixed)
### Additional information
### What does this PR try to resolve?
Fixes#15244
With this fix,
`cargo vendor` will not delete original sources,
if you want to vendor things from one directory sources to the other
#### Background
cargo-vendor has a workaround that to mitigate #5956:
it removes all cached sources in order to trigger a re-unpack.
It was meant for dealing with registry sources only,
but accidentally applied to directory source kind.
While directory source kind was invented for vendoring,
and vendoring from one vendored directory to the other seems unusual,
Cargo IMO should not delete any real sources.
It does not mean that registry sources are okay to delete,
In long term, we should explore a way that unpacks `.crate` files
directly, without any removal. See
https://github.com/rust-lang/cargo/pull/12509#issuecomment-1732415990
### How should we test and review this PR?
The added test should suffice.
Also, although this is for fixing #15244,
`cargo vendor` still doesn't support vendor from and to the same
location.
Unless we figure out an `rsync`-like solutin to update vendor sources,
it is not going to support in short term.
(And I also doubt the real world use case of it)
### Additional information
cargo-vendor has a workaround that to mitigate rust-lang/cargo#5956,
it removes all cached sources in order to trigger a re-unpack.
It was meant for dealing with registry sources only, but accidentally
applied to directory source kind.
While directory source kind was invented for vendoring,
and vendoring from one vendored directory to the other seems unusual,
Cargo IMO should not delete any real sources.
It does not mean that registry sources are okay to delete,
In long term, we should explore a way that unpacks `.crate` files
directly, without any removal. See
https://github.com/rust-lang/cargo/pull/12509#issuecomment-1732415990
vaue -> value
<!--
Thanks for submitting a pull request 🎉! Here are some tips for you:
* If this is your first contribution, read "Cargo Contribution Guide"
first:
https://doc.crates.io/contrib/
* Run `cargo fmt --all` to format your code changes.
* Small commits and pull requests are always preferable and easy to
review.
* If your idea is large and needs feedback from the community, read how:
https://doc.crates.io/contrib/process/#working-on-large-features
* Cargo takes care of compatibility. Read our design principles:
https://doc.crates.io/contrib/design.html
* When changing help text of cargo commands, follow the steps to
generate docs:
https://github.com/rust-lang/cargo/tree/master/src/doc#building-the-man-pages
* If your PR is not finished, set it as "draft" PR or add "WIP" in its
title.
* It's ok to use the CI resources to test your PR, but please don't
abuse them.
### What does this PR try to resolve?
Explain the motivation behind this change.
A clear overview along with an in-depth explanation are helpful.
You can use `Fixes #<issue number>` to associate this PR to an existing
issue.
### How should we test and review this PR?
Demonstrate how you test this change and guide reviewers through your
PR.
With a smooth review process, a pull request usually gets reviewed
quicker.
If you don't know how to write and run your tests, please read the
guide:
https://doc.crates.io/contrib/tests
### Additional information
Other information you want to mention in this PR, such as prior arts,
future extensions, an unresolved problem, or a TODO list.
-->
# What does this PR try to resolve?
Currently third party subcommands like `cargo asm` from
[`cargo-show-asm`] don't
support shell completions, even when the corresponding `cargo-<cmd>`
command *does*.
(I'm using `cargo asm` as example because it was the first subcommand
that came
into mind that provides completions)
This PR fixes this for `bash` by using [`bash-completion`]'s
[`_comp_command_offset`] function to generate these completions.
(Assuming these completions are available to [`bash-completion`])
[`bash-completion`] is the package that is used by all major unix-like
operating
systems to provide bash completions.
If the subcommand has no completion, that falls back to the default
bash.
(That might not be *exactly* the same as `_filedir`, but should be
correct anyway)
**Note** that [`_comp_command_offset`] is only supported since
[`bash-completion`] >= `2.12.0`,
which requires `bash` >= `4.2.0`, which means that the default
`bash` version shipped with MacOs is **not** supported. \
In that case we fall back to the previous behavior with `_filedir`.
# How should we test and review this PR?
I'm not sure if there is any testing setup for shell completions for
`cargo`.
I have just tested it manually by running these commands:
(In the working directory of this PR)
```bash
#!/usr/bin/env bash
# Install the subcommand
cargo install cargo-show-asm
# Load the completions for `cargo-asm`
eval "$(cargo-asm --bpaf-complete-style-bash)"
# (Re)source the new cargo completions
source src/etc/cargo.bashcomp.sh
```
and then tab-completing from `cargo asm <TAB>`.
# Additional information
## Further Possibilities
The same trick with [`_comp_command_offset`] could be used to get
completions
for the command run with `cargo run -- `, assuming there is an easy way
to get
the name of the binary that would be run. (And maybe something to
dynamically (re)-load the completions.)
## Prior Art
The `zsh`-completions already support the `zsh`-equivalent of this with
<58cfd96b59/src/etc/_cargo (L368-L372)>
[`cargo-show-asm`]: https://docs.rs/cargo-show-asm
[`bash-completion`]: https://github.com/scop/bash-completion/
[`_comp_command_offset`]:
92f558d582/bash_completion (L2816-L2821)
Overwrite `$CARGO` when the current exe is detected to be a cargo
binary.
From
https://github.com/rust-lang/cargo/issues/15099#issuecomment-2666737150:
> opt-in behavior (set by cargo-the-bin):
>
> 1. `from_current_exe` if its `cargo[EXE_SUFFIX]`
> 2. `from_argv` if its `cargo[EXE_SUFFIX]`
> 3. `from_env`
> 4. `from_current_exe`
> 5. `from_argv`
r? @epage
### What does this PR try to resolve?
The old behavior gets members from `default-members` if specified in a
virtual workspace, this PR gets all workspace members for `Available`
target hints.
Fixes https://github.com/rust-lang/cargo/issues/14544
### How should we test and review this PR?
The first commit added the test, the second commit addressed the issue.
### Additional information
### What does this PR try to resolve?
Just found we can simplify `human_readable_bytes` a bit.
This also remove the `bytesize` dependency,
since we already have a hand-rolled function.
(It is a good crate, though)
### How should we test and review this PR?
Should have no real functional difference.
`cargo package` starts reporting IEC (KiB) instead of SI (KB).
So do some thresholds of `cargo package`.
Could also switch entirely to `bytesize` if that is preferred.
### Additional information
### What does this PR try to resolve?
This likely only affects `-Zpackage-workspace` but it might have also
broken dependencies whose path ends with `.rs` as
well
This broke in https://github.com/rust-lang/cargo/pull/14961
### How should we test and review this PR?
### Additional information
GitHub Runner Images 20250224.5.0+ ship Windows 11 SDK 10.0.26100+ from
the previous Windows 11 SDK 10.0.22621, which bumped the UCRT headers.
The new UCRT headers use SSE2 types. However, `cc` versions <= 1.2.15
emit `/arch:IA32` for `x86` Windows targets for `clang-cl`, which causes
compilation errors since `clang-cl` can't find SSE2 types without
`/arch:SSE2` specified (or defaulted). (Note that MSVC at the time of
writing silently accepts and emits instruments for code using SSE2
types, as opposed to `clang-cl` hard error-ing).
To fix this for rust-lang/rust CI, we need to bump anything that
transitively relies on `cc` and tries to use `clang-cl` on `x86` Windows
targets to compile any C/C++ code that transitively use functions or
types that require SSE2 types, such as `<wchar.h>`. `cc` 1.2.16 contains
<https://github.com/rust-lang/cc-rs/pull/1425> which emits `/arch:SSE2`
instead of `/arch:IA32` for `x86` Windows targets when using `clang-cl`.
