<!--
_Thanks for the pull request 🎉!_
_Please read the contribution guide: <https://doc.crates.io/contrib/>._
-->
### What does this PR try to resolve?
Fixes#16683 by adding manuall truncate.
<!--
_Explain the motivation behind this change._
_A clear overview along with an in-depth explanation are helpful._
-->
### How to test and review this PR?
See the original issue for mCVE.
<!--
_Demonstrate how you test this change and guide reviewers through your
PR._
_With a smooth review process, a pull request usually gets reviewed
quicker._
-->
When cross compiling (with `--target`), cargo panics with -Zhost-config.
This changes the explicit addition of the host target to only occur if
the `requested_kinds` includes the host.
Otherwise looking up the target_runner for the explicit_host_kind
attempts to look up an entry in the target_config map that does not
exist.
This fixes a (very small) typo in the docs for `cargo-yank`.
Specifically, since "unintentional SemVer breakages" is plural, the "an"
that was at the beginning of that sentence was incorrect.
### What does this PR try to resolve?
There wasn't an issue, just a very tiny typo
### How to test and review this PR?
Hopefully this shouldn't need any testing... it's just a change to a
markdown file
This fixes a (very small) typo in the docs for `cargo-yank`. Specifically,
since "unintentional SemVer breakages" is plural, the "an" that was
at the beginning of that sentence was incorrect.
fixes#16637
Clippy lints can be enabled via the command line via `cargo clippy -- -Wclippy::lint`, and these need to be included in the `cargo fix` command for the emitting lints to actually be fixed.
Thus, add them to the "run `..` to apply .. suggestions" message.
Only suggest when running from clippy-driver
This commit replaces a `Mutex` with an `RwLock` lock to avoid holding a
mutex guard while waiting on a file lock. Instead we hold a read guard
which allows multiple threads to access the `HashMap` inside of
`LockManager`.
### What does this PR try to resolve?
This PR updates the layout module docs to reflect the update layout
structure changes made as part of
https://github.com/rust-lang/cargo/issues/15010
### How to test and review this PR?
no response
### Follow up needed
- [ ] Add a note in the tracking issue to updating these docs in the
stabilization PR
### What does this PR try to resolve?
Similar to <https://github.com/rust-lang/cargo/pull/16638>,
this prevents `host.linker` from applying to non-host build targets.
### How to test and review this PR?
This behavior has been there since the integration of host-config, so it
_might_ break somebody's assumption.
I've checked the use of `target_linker`:
* doctest continues using `target_linker` as it is more a target builds:
312145c006/src/cargo/core/compiler/build_runner/mod.rs (L281-L289)
* `RUSTC_LINKER` set for build scripts is on the same boat. It indicates
the linker to use for the associated crate, which is always a target
build:
312145c006/src/cargo/core/compiler/custom_build.rs (L389-L391)
Other than the two above, the other usages of it (fingerprint, and rustc
invocation) should respect host.linker when building build script
exectuables.
This commit changes the directory name of the `output` file to `stdout` in
order to match the naming of `stderr` and better represent the contents
it contains.
`host.runner` was incorrectly applied to non host units like proc macros
and build scripts when `-Zhost-config` was enabled but no `--target` flag
was specified.
The root cause was that `target_linker()` used `target_config(kind)`
which routes through `host_config` for `CompileKind::Host`. But
`CompileKind::Host` is used for both build scripts and normal binaries
when no `--target` is specified.
`host.runner` was incorrectly applied to `cargo run` and other target
processes when `-Zhost-config` was enabled but no `--target` flag was
specified.
The root cause was that `target_runner()` used `target_config(kind)`
which routes through `host_config` for `CompileKind::Host`. But
`CompileKind::Host` is used for both build scripts and normal binaries
when no `--target` is specified.
### What does this PR try to resolve?
Simplify code structure in order to the future support of displaying
nested command man pages (broken out from
<https://github.com/rust-lang/cargo/pull/16432>).
### How to test and review this PR?
### What does this PR try to resolve?
This is a regression found in rust-lang/compiler-builtins#1087
and introduced by rust-lang/cargo#16599
There are other regression that `host.runner` and `host.linker`
are accidentally applied to target builds which I plan to fix
both in a follow-up PR.
(rust-lang/cargo#12535 introduced the `host.linker` bug btw)
This is a regression found in rust-lang/miri#4855
and introduced by rust-lang/cargo#16599
There are other regression that `host.runner` and `host.linker`
are accidentally applied to target builds which I plan to fix
both in a follow-up PR.
(rust-lang/cargo#12535 introduced the `host.linker` bug btw)
### What does this PR try to resolve?
### How to test and review this PR?
Found while working on #16612 and realized I had a good regex for
identifying them: `rg 'ERROR..[A-Z]' tests/`
I also fixed the wording on some but more could likely use some wording
improvements.
### What does this PR try to resolve?
Fixes the FIXME in `workspace.rs` by switching to `pathdiff`. This
creates a relative path independent even when outside of the workspace
root.
### How to test and review this PR?
- Added regression tests in `tests/testsuite/workspace.rs`.
- Verified error message formatting for members outside the workspace.
### What does this PR try to resolve?
This PR makes more changes to the new `build-dir` layout as discussed in
https://github.com/rust-lang/cargo/pull/16502#discussion_r2686485984.
The goal here is to have more general (and thus reusable) directories in
the build unit structure.
#### Layout changes
1. Rename `{build-unit-dir}/deps` to `{build-unit-dir}/out`
2. Moved build-script `OUT_DIR` from `{build-unit-dir}/build-script/out`
to `{build-unit-dir}/out`
3. Renamed `{build-unit-dir}/build-script` to `{build-unit-dir}/run`
* This makes the dir more general to any build unit that can execute an
external process. (but currently only build-scripts use it)
The resulting structure looks like
```
build-dir/debug/build/<pkgname>/<HASH>
fingerprint/
out/
run/
.lock
```
Part of https://github.com/rust-lang/cargo/issues/15010
### How to test and review this PR?
See the test updates included in each commit
```
error: could not compile `issue-16622` (bin "issue-16622") due to 1 previous error
error: failed to compile `issue-16622 v0.0.0 ([…]/issue_16622)`, intermediate artifacts can be found at `[…]/issue_16622/target`.
To reuse those artifacts with a future compilation, set the environment variable `CARGO_TARGET_DIR` to that path.
```
currently points to the target directory.
However, intermediate artifacts are stored in the directory configured by `build.build-dir`,
so the message should be updated to point to that path and corresponding environment variable instead.
This commit changes the build script execution dir from `{build-unit-dir}/build-script`
to `{build-unit-dir}/run`. The motivation behind this is to have a
general directory for units that execute some binary/external process
and output to stdout/err. Currently this is only used by build-scripts
but could be expanded in the future.
This commit moves the build-script OUT_DIR location from `{build-unit-dir}/build-script-execution/out`
to `{build-unit-dir}/out` dir (that was previously `{build-unit-dir}/deps`)
This was previously indirectly created by `OUT_DIR`, however in the
future `OUT_DIR` will not be nested in the build-script run dir so we
always want to create it.
Previously `deps` was only the compiler output. This commit renames it
to `out` to make it more general to any kind of build output.
The build script OUT_DIR will eventually be merged into this directory.
### What does this PR try to resolve?
This was the original behavior.
There was some concern over this previously and we switched to only
loading config from CARGO_HOME in #14749.
After discussing this in today's cargo team meeting, we decided to
switch it back.
A concern brought up previously was if you previously downloaded a
config and now download and run a script, you could get surprising
behavior, maybe even dangerous.
This does require some extra hoops because you don't have a
`.cargo.toml` but a `.cargo/config.toml`.
You can't directly download that but must first download a zip file and
then decompress it without it having a parent directory.
Contrast that with users who have a script in their repo and config that
should apply to it.
This is an important use case but one we will get less feedback on
during calls for testing.
In discussing this, we felt there are different use cases:
- The repo with a config file
- People surprised at how config loading works
We settled on this change because it is consistent with the current
behavior, even if it can be confusing and undesirable. We can then work
to improve the overall config search path experience and both regular
cargo commands and running of cargo scripts would benefit.
### How to test and review this PR?
This reverts commit bd47da1ab129ac6c086f74892327f3896f9f847c.
