Report cmd aliasing failure with more contexts
### What does this PR try to resolve?
Commands aliasing resolution should report TOML parsing error to users.
Fixes#11013.
### How should we test and review this PR?
https://github.com/rust-lang/cargo/pull/11087/commits/ef7a4ef is the most important commit in this PR. `has_key` now throws errors after this PR, so any use `Config::get<Option<…>>()` is affected if there is a malformed config. Had a skim over all usages of `get::<Option<…>>`, `get_string` and `get_path`, I don't feel any of them should ignore errors.
fix(cli): Forward non-UTF8 arguments to external subcommands
Whether we allow non-UTF-8 arguments or not, we shouldn't preclude external subcommands from deciding to do so.
I noticed this because clap v4 changed the default for external subcommands from `String` to `OsString` with the assumption that this would help people to "do the right thing" more often.
This change adds an example to the authors attribute in the manifest.
It is submitted to clarify the documenation for new folks such as
myself. See the forum issue linked below which prompted this change
since the error message the compiler issues is not clear for new
folks.
https://users.rust-lang.org/t/compile-error-when-adding-authors-to-cargo-toml/79383
Thank you for considering this contribution. It's my first so go
easy on me please! :-)
I noticed this because clap v4 changed the default for external
subcommands from `String` to `OsString` with the assumption that this
would push people to "do the right thing" more often.
Some linkers do not remove the executable, but truncate and modify it.
That results in the old hard-link being modified even after renamed.
We delete the old artifact here to prevent this behavior from confusing users.
See rust-lang/cargo#8348.
clap 3.1 renamed `App` to `Command`. When we upgrade to clap v4, the
lifetime will be removed and we can just use `clap::Command` instead of
a type alias. This is prep for that.
Add a minor clarification
### What does this PR try to resolve?
It tries to clarify the overriding build scripts section. We spent over an hour with 3 people trying to get it to work and it was extremely difficult to figure out.
### How should we test and review this PR?
N/A
### Additional information
N/A
This gives users of custom registries the same protections, using the
same size limit that crates.io uses.
`LimitErrorReader` code copied from crates.io.
Notable changes:
- Add/improve module documentation.
- Add missing item documentation.
- Add "editable" to `Dependency` and `Manifest` to further distinguish them from
similarly named items in the library.
Stylistic changes:
- Terminate doc comments with a period.
- Wrap doc comments.
Take priority into account within the pending queue
This is the PR for the work discussed in [this zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/pending.20queue.20scheduling.20experiments) and whose detailed description and some results are available [here](https://github.com/lqd/rustc-benchmarking-data/tree/main/experiments/cargo-schedules/pending-queue-sorted) with graphs, summaries and raw data -- much of which was shown in the thread as well.
Units of works have a computed priority that is used in the dependency queue, so that higher priorities are dequeued sooner, as documented [here](996a6363ce/src/cargo/util/dependency_queue.rs (L34-L35)).
This PR further applies that principle to the next step before being executed: if multiple pieces of work are waiting in the pending queue, we can sort that according to their priorities. Here as well, higher priorities should be scheduled sooner.
They are more often than not wider than pure chains of dependencies, and this should create more parallelism opportunities earlier in the pipeline: a high priority piece of work represents more future pieces of work down the line, and try to sustain CPU utilization longer (at the potential cost of this parallelism being distributed differently than today, between cargo invoking rustc and rustc's own codegen threads -- when applicable).
This is a scheduling tradeoff that behaves differently for each project, machine configuration, amount of available parallelism at a given point in time, etc, but seems to help more often than hinders: at low-core counts and with enough units of work to be done, so that there is jobserver token contention where choosing a "better" piece of work to work on next may be possible.
There's of course a bit of noise in the results linked above and 800 or so of the most popular crates.io crates is still a limited sample, but they're mostly meant to show a hopefully positive trend: while there are improvements and regressions, that trend looks to be more positive than negative, with the wins being more numerous and with higher amplitudes than the corresponding losses.
(A report on another scheduling experiment -- a superset of this PR, where I also simulate users manually giving a higher priority to `syn`, `quote`, `serde_derive` -- [is available here](https://github.com/lqd/rustc-benchmarking-data/tree/main/experiments/cargo-schedules/pending-queue-prioritized) and also improves this PR's results: the regressions are decreased in number and amplitude, whereas the improvements are bigger and more numerous. So that could be further work to iterate upon this one)
Since this mostly applies to clean builds, for low core counts, and with a sufficient number of dependencies to have some items in the pending queue, I feel this also applies well to CI use-cases (esp. on the free tiers).
Somewhat reassuring as well, and discussed in the thread but not in the report: I've also tried to make sure cargo and bootstrapping rustc are not negatively affected. cargo saw some improvements, and bootstrap stayed within today's variance of +/- 2 to 3%. Similarly, since 3y old versions of some tokio crates (`0.2.0-alpha.1`) were the most negatively affected, I've also checked that recent tokio versions (`1.19`) are not disproportionately impacted: their simple readme example, the more idiomatic `mini-redis` sample, and some of my friends' tokio projects were either unaffected or saw some interesting improvements.
And here's a `cargo check -j2` graph to liven up this wall of text:
---
I'm not a cargo expert so I'm not sure whether it would be preferable to integrate priorities deeper than just the dependency queue, and e.g. have `Unit`s contain a dedicated field or similar. So in the meantime I've done the simplest thing: just sort the pending queue and ask the units' priorities to the dep queue.
We could just as well have the priority recorded as part of the pending queue tuples themselves, or have that be some kind of priority queue/max heap instead of a Vec.
Let me know which you prefer, but it's in essence a very simple change as-is.
fix(add): Clarify which version the features are added for
### What does this PR try to resolve?
This gives a hint to users that we might not be showing the feature list
for the latest version but the earliest version.
Also when using a workspace dependency, this is a good reminder of what the version requirement is that was selected. That could also be useful for reused dependencies but didn't want to bother with the relevant plumbing for that.
ie we are going from
```console
$ cargo add chrono@0.4
Updating crates.io index
Adding chrono v0.4 to dependencies.
Features:
- rustc-serialize
- serde
```
to
```console
$ cargo add chrono@0.4
Updating crates.io index
Adding chrono v0.4 to dependencies.
Features as of v0.4.2:
- rustc-serialize
- serde
```
### How should we test and review this PR?
I'd recommend looking at this commit-by-commit. This is broken up into several refactors leading up the main change. The refactors are focused on pulling UI logic out of dependency editing so we can more easily evolve the UI without breaking the editing API. I then tweaked the behavior in the final commit to be less redundant / noisy.
The existing tests are used to demonstrate this is working.
### Additional information
I'm also mixed on whether the meta version should show up.
Fixes#11073
The workspace behavior doesn't seem to be documented at all, so a blurb
was brought in that is like the profile blurb. The workspace docs then
link out to it so users can be aware of this special workspace behavior.
In a workspace, only the workspace's profile is respected. This is
already documented in the profile documentation but we should raise
visibility of it within the workspace documentation.
In looking over #10625, I remembered we've been having growing pains
with the workspace documentation. It was originally written when there
were a lot fewer workspace features. As more workspace features have
been added, they've been tacked on to the documentation.
This re-thinks the documentation by focusing on the schema, much like
`manifest.md` does.
bors
Aleksey Kladov
Weihang Lo
P. Todd Decker
Ed Page
x-hgg-x
Emil Gardström
Duncan Ogilvie
Weihang Lo
Josh Triplett
Cassaundra Smith
Ryan Butler
