Whether a period was used was dependent on whether a `help:` block is
present.
That shouldn't make a difference and the rustc dev guide says not to use
periods unless multiple sentences are used.
I was going to add another duplicate and was wondering what was the
right value and figured it'd be better if I just did this.
<!--
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?
Since `rust 1.85.0`, It is no longer sufficient to use the `unsafe`
keyword only at the call site. It must also be applied to the `extern`
statement, hence, Cargo Book must be updated
- closes https://github.com/rust-lang/cargo/issues/15289
and also update some more related content
### How should we test and review this PR?
Run `mdbook build`. The `unsafe extern` should be seen at
`cargo/reference/build-script-examples.html#linking-to-system-libraries`
, `cargo/reference/build-script-examples.html#building-a-native-library`
, `cargo/reference/semver.html#repr-c-shuffle` ,
`cargo/reference/semver.html#repr-c-remove` and
`cargo/reference/semver.html#repr-transparent-remove`
### Additional information
### What does this PR try to resolve?
A few terminal emulators support progress output to Windows taskbar.
`winget` uses this to show install progress.
Notably, Windows Terminal [recently (2020) added
support](https://github.com/microsoft/terminal/pull/8055) for ANSI codes
[specified](https://conemu.github.io/en/AnsiEscapeCodes.html#ConEmu_specific_OSC)
in ConEmu (another terminal emulator for Windows) documentation. Also,
in "[Learn
Windows](https://learn.microsoft.com/en-us/windows/terminal/tutorials/progress-bar-sequences)".
I've found the previous attempt to add this feature:
https://github.com/rust-lang/cargo/pull/11436
As per @weihanglo's request, I've added the config option to
enable/disable this feature. **It's enabled on supported terminal
emulators.**
Fixes#11432
FCP:
https://github.com/rust-lang/cargo/pull/14615#issuecomment-2546346489
### How should we test and review this PR?
Run `cargo build` in Windows Terminal with configuration option
`term.progress.taskbar` set to `true`.
### Not sure
- [x] Should all the code be `#[cfg(windows)]`? Probably no, because the
feature is also usable in WSL.
> Solved by introducing heuristic based on environment variable set by
terminal
- [ ] If Ctrl+C is pressed, a progressbar will stay in a last state
forever (shown in the ConEmu video). `winget` is also behaves like
alike. I've experimented with `ctrl_c handler` and it's totally fixable.
- [x] `Enabled` is a sensible default for WSL because it works on linux
builds in Windows Terminal too
> Solved by introducing heuristic based on environment variable set by
terminal
- [x] Downloading stage may produce unpleasant blinking due to a rapid
0-100 changes
> Solved by not displaying bar when downloading and using indeterminate
state in other cases so amination don't reset
### TLDR
* An `term.progress.taskbar` option with bool type is added
* On Windows Terminal and ConEmu is enabled by default
* If enabled reports build progress to taskbar icon and/or tab header
### Videos
https://github.com/user-attachments/assets/48bb648a-e819-490e-b3ac-3502bc5f2f3ahttps://github.com/user-attachments/assets/1d7ddf7a-34dd-4db1-b654-e64d7170798e
<!--
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?
Related to https://github.com/rust-lang/cargo/issues/14520
This PR introduces auto-completion for the `cargo add --path` option.
When a user types `cargo add --path` and presses the TAB key, the system
will automatically detect directories in the current path and suggestion
prioritizes directory containing a Cargo.toml file.
### How should we test and review this PR?
To verify this feature, follow these steps:
In the terminal, type `cargo add --path`
Press the TAB key.
You should see suggestions only for directories in the current path that
contain a Cargo.toml file being prioritized, such as ./src/ (if
./src/Cargo.toml exists).
https://github.com/user-attachments/assets/0620ae5e-abca-425c-ad9a-7004929bb98d
<!--
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.
### 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?
Related to https://github.com/rust-lang/cargo/issues/14520
This PR introduces auto-completion for the cargo install --path option.
When a user types cargo install --path and presses the TAB key, the
system will automatically detect directories in the current path and
suggestion prioritizes directory containing a Cargo.toml file.
### How should we test and review this PR?
To verify this feature, follow these steps:
1. In the terminal, type `cargo install --path`
2. Press the TAB key.
3. You should see suggestions only for directories in the current path
that contain a `Cargo.toml` file being prioritized, such as `./src/` (if
`./src/Cargo.toml` exists).
https://github.com/user-attachments/assets/281706c0-7956-4551-a22b-125dadccd12e
### Additional information
There's a [discussion in
Zulip](https://rust-lang.zulipchat.com/#narrow/channel/246057-t-cargo/topic/PR15266.3A.20completions.20for.20install.20--path)
and here're some relevant information from it
1. directories are always shown so that a completer doesn't have to
recurse through a directory tree to determine what directories may be
relevant. The difference marking a directory as accepted does it sorts
it first.
2. A user / config setting might override a sort order over native
completion. Try disable it manually if native completion is not there.
Lockfile might not be under the package root, but its entries
may be outdated and get packaged into the `.crate` tarball.
We take a conservative action that if the lockfile is dirty,
then all workspace members are considered dirty.
Workspace manifest might not be under the package root, but
workspace inheritance may still affect what is packaged into
the `.crate.` tarball. We take a conservative action that if
the workspace manifest is dirty, then all workspace members
are considered dirty.
### What does this PR try to resolve?
I was investigating some issues around public dependency lints and
wanted to see the structure of the public dependencies and had the idea
to add this with us having added `--depth workspace`.
See
https://github.com/rust-lang/rust/issues/119428#issuecomment-2686384070
for some example output (comparing `cargo tree` with `cargo tree --depth
public`)
### How should we test and review this PR?
### Additional information
This commit fixes a (five year old!) regression in `cargo metadata`
where if `--filter-platform` isn't explicitly specified it will
accidentally read `$CARGO_BUILD_TARGET` (or `build.target`
configuration) and use that as the default `--filter-platform`. The
reason for this is that the calculation for targets changed in #8167
and while the shared function makes sense for other commands such as
`cargo build` the targets have a different meaning in `cargo metadata`
so a slightly different set of functionality is desired.
This commit fixes the issue by introducing a new constructor for the
list of `CompileKind` variants where the fallback of "if nothing is
specified" is explicitly chosen.
`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>.
### 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
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
# 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)
