Add special `check-cfg` lint config for the `unexpected_cfgs` lint
This PR adds a special `check-cfg` lint config for the `unexpected_cfgs` lint, as it was decided by T-cargo (in today's meeting).
The goal of this lint config is to provide a simple and cost-less alternative to the build-script `cargo::rustc-check-cfg` instruction.
```toml
[lints.rust]
unexpected_cfgs = { check-cfg = ["cfg(foo, values(\"bar\"))"] }
```
Regarding the implementation, everything is as straight forward as possible, nothing over-engineered; I added the possibility to omit the `level` field if a sub-config is specified instead, since it seems useful and was easy to implement.
There are many small-ish commit, I recommend reviewing them independently.
r? `@epage` (or `@weihanglo` maybe)
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.
a6230e348b 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`).
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.
bors
Urgau
Weihang Lo
Steven Engler
Greg Morenz
Justin Smith
Scott Schafer
Tor Hovland
Kevin Reid
Herman Skogseth