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.
refactor(cli): Prepare for clap v4
This is two minor refactors that better align us with the upcoming clap v4
- `clap::ErrorKind` has moved to `clap::error::ErrroKind` during 3.x and in 4.0 the old location no longer works
- `clap::App` was renamed to `clap::Command` and in v4 the lifetime will be removed which will remove the need for us to have an alias at all. This does the rename so we can just use what clap has in v4.
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
Revert "Clarify when cargo detects changes"
Reverts rust-lang/cargo#11092
We had not fully confirmed that this language change matches the new behavior.
docs(ref): Clarify workspace settings
### What does this PR try to resolve?
In reviewing the status of #10625, I was reminded
- that we are having growing pains with the workspace documentation
- that `workspace.resolver` isn't documented
So I re-organized the workspace docs to have a high level intro / behavior description and then to focus on being a field reference, much like `manifest.md`. I could see splitting it specifically into tutorial/reference like the overriding dependencies document does it.
When adding `workspace.resolver`, I remembered in the nested workspace discussion there were other workspace related sections that are not present. We now link out to `profile`, `patch`, and `replace`. In doing this, I realized that `patch` and `replace` do not specify their workspace behavior, so I do that.
### How should we test and review this PR?
Look at it commit by commit to get more digestible chunks. Unfortunately, the first commit didn't split up so easily.
### Additional information
Other information you want to mention in this PR, such as prior arts,
future extensions, an unresolved problem, or a TODO list.
-->
<!-- homu-ignore:end -->
[master] Run `reach_max_unpack_size` test only on debug build
`cargo test --release` fails on test `reach_max_unpack_size` as the binary to exercise is optimized. The alternative approach is removing `cfg!(debug_assertions)` from this line.
<9ef926dafc/src/cargo/sources/registry/mod.rs (L842)>
#11089
Clarify when cargo detects changes
### What does this PR try to resolve?
Its not clear if "any file" means "any rust file" or "any file, including non rust files". I think the confusion stemmed from the focus on it belonging to the rust package. So it was unclear if any file in the directory counts as belonging to the package, or if the package only contains rust source files, and therefore a `.proto` or `.fbs` file in the same directory as the Cargo.toml would not trigger a rebuild.
I amended the wording to focus on directories rather than packages.
### How should we test and review this PR?
Please let me know which change it should be, and I will update my PR accordingly. Also, please let me know if my edit is accurate, or if it is misleading!
[master] Fix for CVE-2022-36113 and CVE-2022-36114
This PR includes the fixes for CVE-2022-36113 and CVE-2022-36114 targeting the master branch. See [the advisory](https://blog.rust-lang.org/2022/09/14/cargo-cves.html) for more information about the vulnerabilities.
Scott Schafer
bors
Aleksey Kladov
Weihang Lo
P. Todd Decker
Ed Page
x-hgg-x
Emil Gardström
Duncan Ogilvie
Ryan Butler
Pietro Albini
Weihang Lo
