This permits things like this to be recognized and passed to
rustc/rustdoc.
```rust
[lints.rust]
unexpected_cfgs = { level = "warn", check-cfg = ["cfg(foo)"] }
```
test: set safe.directory for git repo in apache container
### What does this PR try to resolve?
Failure in container tests due to a new version of `git` package in Alpine Linux Package repository.
See also <https://github.com/rust-lang/cargo/pull/13913#issuecomment-2113712049>
### How should we test and review this PR?
Alpine Linux Package repository 3.19 just bumped git package to 2.43.4 from 2.43.0.
The docker image `httpd:2.4-alpine` we use in container tests failed due to the git version bump.
The `httpd` log shown that
```
240.10.0.1 - - [16/May/2024:03:52:36 +0000] "GET /repos/bar.git/info/refs?service=git-upload-pack HTTP/1.1" 500 -
[16/May/2024:03:52:36 +0000] 240.10.0.1 TLSv1.3 TLS_AES_256_GCM_SHA384 "GET /repos/bar.git/info/refs?service=git-upload-pack HTTP/1.1" -
fatal: detected dubious ownership in repository at '/repos/bar.git'
To add an exception for this directory, call:
git config --global --add safe.directory /repos/bar.git
```
git/git@f4aa8c8bb1 is likely the commit causing problems.
So I ended up adding `git config --system --add safe.directory '*'` to the Dockerfile of apache container.
Note that we need `--system` instead of `--global` because `httpd` are running under the other user www-data, not root.
refactor: misc refactors for `ops::resolve`
### What does this PR try to resolve?
This is a preparation for another `-Zpatch-files` experiment,
so that the future PR can move things around easier without too many conflicts.
### How should we test and review this PR?
Generally they shouldn't affect anything existing behavior.
a6230e348b786420e83cc8220e0d8f4c61084a12 might be a bit dubious,
though I believe preloading workspace members is kinda idempotent
and registering patches/lockfile never cares about it.
### Additional information
Preserve file permissions on unix during `write_atomic`
### What does this PR try to resolve?
Fixes#13896.
> When you run `cargo add`, it changes the file permissions of `Cargo.toml` to 600 (user read+write only). This is a little bit painful when you're building the code as a different user than the user writing the code, for example if you're running the code in a container. This applies to `cargo remove` as well. I tested this behaviour on Cargo 1.78.0 and nightly.
I'm not entirely sure how permissions are handled on Windows, but the tempfile lib [doesn't seem to support them](https://docs.rs/tempfile/3.10.1/tempfile/struct.Builder.html#windows-and-others), so I haven't changed the behaviour on Windows.
Only the user/group/other read/write/execute permission bits are copied.
This PR sets the permissions ~twice~ once:
~1. When creating the file. This has the umask applied, but means that we don't create a file that is more permissive than the original.~
2. After the file has been created. This doesn't apply the umask, resulting in the file having the same u/g/o r/w/x permissions as the original file.
Since this PR changes a util function, it has a wider scope than just changing the behaviour of `cargo add` and `cargo remove`. `write_atomic` is called from the following functions:
- [`migrate_manifests`](4de0094ac7/src/cargo/ops/fix.rs (L340))
- [`update_manifest_with_new_member`](4de0094ac7/src/cargo/ops/cargo_new.rs (L1008))
- [`LocalManifest::write`](4de0094ac7/src/cargo/util/toml_mut/manifest.rs (L299))
- [`gc_workspace`](4de0094ac7/src/bin/cargo/commands/remove.rs (L274))
### How should we test and review this PR?
Unit test was added (`cargo test -p cargo-util write_atomic_permissions`).
To coordinate diagnositcs between different cargo-as-rustc-proxies,
`cargo fix` launches a diagnostc server on localhost.
However, the TCP server was hard-coded with an IPv4 address 127.0.0.1,
which didn't work with IPv6-only network.
This commit fixes the issue by attempting to bind both IPv6 and IPv6
localhost addessses.
Fix docs for unstable script feature
### What does this PR try to resolve?
* [Recent change](https://github.com/rust-lang/cargo/pull/13861) to accepted syntax in the script feature is not reflected in the documentation.
### How should we test and review this PR?
* Verify that this documentation is consistent with syntax expected.
### Additional information
N/A
Refactor cargo lint tests
In #13621, it was brought up that [the lints tests are nested more deeply than other UI tests](https://github.com/rust-lang/cargo/pull/13621#discussion_r1538065181). This got me wondering if there was a better way to structure all the lint tests.
What I came up with was:
- Lints should not have UI tests, only parts of the diagnostic system, i.e., how warnings, errors, notes, etc., look
- This is because UI tests should focus on parts of the system that make up each lint's output
- We can always add UI tests for each lint if desired
- All tests related to the linting system should live in `tests/testsuite/lints/`
- Tests related to `[lints.cargo]` should stay in `lints_table.rs` as it is for the whole lints table
- Each lint will get a file in `lints/` for all of its tests
- This makes `lints/mod.rs` smaller and targeted only at tests for the linting system itself
- It makes it much easier to know where to place a test
Old syntax suggestion
Fixes#13868.
The build error in the issue will now include a suggestion:
```
Compiling zerocopy v0.8.0-alpha.9
error: the `cargo::` syntax for build script output instructions was added in Rust 1.77.0, but the minimum supported Rust version of `zerocopy v0.8.0-alpha.9` is 1.56.0.
Consider using the old `cargo:` syntax in front of `rustc-check-cfg=`.
See https://doc.rust-lang.org/cargo/reference/build-scripts.html#outputs-of-the-build-script for more information about build script outputs.
```
The suggestion is only included for reserved prefixes.
A test has been added.
Add local-only build scripts example in check-cfg docs
This PR adds an example about creating/having "local-only" build scripts in the check-cfg docs.
r? `@weihanglo`
cc `@epage`
chore: Add cargo-lints to unstable docs
When originally implementing a linting system for `cargo`, I missed adding it to the unstable docs. This PR adds (basic) documentation for `[lints.cargo]`/`-Zcargo-lints` to the unstable docs.
test: clean up unnecessary uses of `match_exact`
It was found during the review of <https://github.com/rust-lang/cargo/pull/13842#discussion_r1591789376>
We should be happy using `assert_match_exact` directly.
The extra arguments to `match_exact` are not necessary for those test cases.
Fix: Build only the specified artifact library when multiple types are available
### What does this PR try to resolve?
Fixes#12109.
#### TL;DR:
A crate `bar` exposes it's library as both a `staticlib` and a `cdylib`. A second crate `foo` specifies an artifact dependency of type `staticlib` on `bar`, meaning cargo should build `bar` as a `staticlib` and expose certain environment variables (e.g. `CARGO_STATICLIB_FILE_BAR`). However, due to a bug, cargo ends up building (and exposing the associated environment variables) for both the `staticlib` and `cdylib`.
The same happens if `foo` specifies an artifact dependency of type `cdylib`; both artifact types are built.
### How should we test and review this PR?
The first commit introduces a test which reproduces the issue, the second commit introduces the fix. This setup was recommended by `@ehuss.`
### Additional information
Artifact dependencies: https://rust-lang.github.io/rfcs/3028-cargo-binary-dependencies.html
#### TL;DR
If a crate `foo` requests an artifact dependency of kind <artifact_kind> from a crate `bar` then the following happens:
- `bar` is built with crate-type <artifact_kind> and a directory is created at `target/<profile>/deps/artifact/bar-<build_hash_or_something>/<artifact_kind>`. The binary artifact is placed in this directory.
- Cargo exposes certain environment variables, the most important for this PR is `CARGO_<artifact_kind>_FILE_BAR`, which points to the binary artifact that was specified. This environment variable is available at compile time for normal dependencies and at runtime for build-dependencies.
If multiple artifact-kinds are requested cargo will create a unit for each, and so they will all be built separately.
