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.
Add more documentation to `cargo::rustc-check-cfg`
This PR add more documentation to `cargo::rustc-check-cfg` by:
1. mentioning `cargo:rustc-check-cfg` for MSRV
2. it also add a link to [the check-cfg blog post](https://blog.rust-lang.org/2024/05/06/check-cfg.html) (since it gives a big overview of the feature in general)
3. it also adds a link to the build-script-examples page where a more complete example for the use of `cargo::rustc-cfg` and `cargo::rustc-check-cfg` is displayed
Fixes https://github.com/rust-lang/cargo/issues/13868
r? `@weihanglo`
fix(toml): Remove unstable rejrected frontmatter syntax for cargo script
### What does this PR try to resolve?
With rust-lang/rfcs#3503 approved, we no longer need to allow easy, high fidelity experiments with alternative cargo script syntax.
### How should we test and review this PR?
### Additional information
We still need to improve the experience for users writing bad syntax but that can come later.
Update UI example code in contributor guide
This updates the UI example case code in paragraph ["Writing Tests"](https://doc.crates.io/contrib/tests/writing.html#ui-tests) of the Cargo Contributor Guide. The previous code snippet did not compile successfully anymore.
Fix global_cache_tracker::max_download_size test flakiness
This (hopefully) fixes an issue where the `global_cache_tracker::max_download_size` test was sporadically failing on CI. My theory is that the `populate_cache` function was inconsistently saving entries with either the same timestamp or timestamps that differed by 1 second. The SQL query in `get_registry_items_to_clean_size_both` sorts the results based on `(timestamp,name)`. Thus if the timestamps were the same, it was sorting on name. If they differed, then the timestamp would dominate. The solution is to force the tests to use the same basis for the starting time so that a function call like `days_ago(1)` returns consistent results.
I don't have a particularly good way to reproduce the issue. Adding a sleep into `populate_cache` causes 100% errors. Running on a slowed down system, or perhaps GitHub Actions might also reproduce, but I did not try.
