I'm unsure how we should be replacing these use cases, so I'm exploring
keeping them but making them use snapbox under the hood.
Part of the intent of snapbox is that it provides you the building
blocks to make what you need.
While this is noisy and hides other deprecations, I figured deprecations would
make it easier for people to discover what tasks remain and allow us to
divide and conquer this work rather than doing a heroic PR.
In theory, this will be short lived and we'll go back to seeing
deprecations in our tests.
Those new tests tries to be as exhaustive as possible while being
reasonable in the number of them. To do so we try to check for
check/doc/test/build-script/features with a the `check-cfg` config.
Many of those tests are very similar to their non-config counterpart.
This permits things like this to be recognized and passed to
rustc/rustdoc.
```rust
[lints.rust]
unexpected_cfgs = { level = "warn", check-cfg = ["cfg(foo)"] }
```
Add `docsrs` cfg as a well known `--check-cfg`
Now that https://github.com/rust-lang/docs.rs/pull/2390 has been merged we can add the `docsrs` cfg in Cargo well known --check-cfg "list". The `docsrs` cfg used by at least [3k project on GitHub](https://github.com/search?q=lang%3Atoml+%2Frustdoc-args+%3D+%5C%5B%22--cfg%22%2C+%22docsrs%22%5C%5D%2F+NOT+is%3Afork&type=code&repo=&langOverride=&start_value=1) alone; including the cfg will help reduce the impact of enabling by default this feature.
> We include it here (in Cargo) instead of rustc, since there is a much closer relationship between Cargo and docs.rs than rustc and docs.rs. In particular, all users of docs.rs use Cargo, but not all users of rustc (like Rust-for-Linux) use docs.rs.
This is part of the last remaining bits of the `--check-cfg` feature.
r? `@epage`
Include declared list of features in fingerprint for `-Zcheck-cfg`
This PR include the declared list of features in fingerprint for `-Zcheck-cfg` (#10554)
`--check-cfg` verifies that `#[cfg()]` attributes are valid in Rust code, which includes `--cfg features foo` definitions that came from `[features]` tables in `Cargo.toml`. For us to correctly re-check cfgs on feature changes,we need to include them in the fingerprint.
For example, if a user deletes an entry from `[features]`, they should then get warnings about any `#[cfg()]` attributes left in the code. Without this change, that won't happen. With this change, it now does.
Otherwise changing (add, removing, ...) features from the `[features]`
table would not cause rustc to be called with the new `--check-cfg`,
showing potentially outdated warnings.
I've wanted something like this myself. I dislike using `--open`
because I tend to move up to re-run my `cargo doc` run but then have to
edit it to remove `--open`.
Also makes it annoying when opening docs when `cargo doc` is wrapped by
a tool like `make`.
This was previously attempted in #5592:
- Unlike the request in #5562, this aligns with #5592 in always printing
rather than using a flag as this seems generally useful
- Unlike #5592, this prints as an alternative to "Opening" to keep
things light
- Unlike #5592, this prints afterwards as the link is only valid then
Fixes#5562
This commit removes all the -Zcheck-cfg options (features, names,
values, output), as they don't make much sense now since features, names
and values are all combine together for upstream rustc and the output
option was only here because the other were.
Now the new behavior from cargo is to always pass one `--check-cfg`
argument to rustc for the `feature`s which implicitly enables well known
names and values.
