Deny warnings in CI, not locally
### What does this PR try to resolve?
The problem with #![deny(warnings)] is it makes iteration more difficult as you might have intermediate states with warnings. Its slightly better that we defer this to cargo test --lib but that still means you can't run a subset of tests against your experiment until you've cleaned up all of your warnings. This can lead to users [working around the problem which could accidentally slip in](d92d04840c).
### How should we test and review this PR?
The first round for this PR includes a warning in the `cargo` crate to ensure it breaks CI. It will then be reverted.
### Additional information
See also https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/.60.23!.5Bcfg_attr.28test.2C.20deny.28warnings.29.29.5D.60
Replace `winapi` with `windows-sys` crate.
### What does this PR try to resolve?
replace `winapi` with `windows-sys` crate.
It's officially maintained.
### How should we test and review this PR?
I just do the replacement of API. I think it is quite clear.
And I found a `cfg` for `windows` may miss checked error.
### Additional information
No one.
Make cargo aware of dwp files.
When using -Csplit-debuginfo=packed on Linux, rustc will produce a dwp file. Unlike the dwo files, whose paths are embedded into the binary, there's no information in the binary to help a debugger locate a dwp file. By convention, the dwp file for `<EXE>` is given the name `<EXE>.dwp` and placed next to `<EXE>`.
When cargo hardlinks the executable file rustc put in target/debug/deps into target/debug, it also needs to hardlink the dwp file along with it. Failing to do this prevents the debugger from finding the dwp file when the binary is executed from target/debug, as there's no way for the debugger to know to look in the deps subdirectory.
The split_debuginfo option is passed down into file_types to make this possible. For cargo clean manual handling is added to match the other split_debuginfo files. bin_link_for_target also passes in None because it won't care about the dwp file.
When using -Csplit-debuginfo=packed on Linux, rustc will produce a dwp file.
Unlike the dwo files, whose paths are embedded into the binary, there's no
information in the binary to help a debugger locate a dwp file. By convention,
the dwp file for <EXE> is given the name <EXE>.dwp and placed next to <EXE>.
When cargo hardlinks the executable file rustc put in target/debug/deps into
target/debug, it also needs to hardlink the dwp file along with it. Failing to
do this prevents the debugger from finding the dwp file when the binary is
executed from target/debug, as there's no way for the debugger to know to look
in the deps subdirectory.
chore: Fix typos
Seeing several typo PRs, like #11560, I figured I'd run my source code spell checker on cargo to help catch a lot of these earlier, in one big batch.
There is a soundness issue with atty when building on Windows with a
custom allocator.
This PR switches direct dependencies on atty to is-terminal. New semver
compatible versions of clap and snapbox remove atty. #11417 upgrades
env_logger to remove it from there.
Fixes#11415
Change rustdoc-scrape-examples to be a target-level configuration
This PR addresses issues raised in rust-lang/cargo#9525. Specifically:
1. It enables examples to be scraped from `#[test]` functions, by passing additional flags to Rustdoc to ensure that these functions aren't ignored by rustc.
2. It moves the `arg` from `-Z rustdoc-scrape-examples={arg}` into a target-level configuration that can be added to Cargo.toml.
The added test `scrape_examples_configure_target` shows a concrete example. In short, examples will be default scraped from Example and Lib targets. Then the user can enable or disable scraping like so:
```toml
[lib]
doc-scrape-examples = false
[[test]]
name = "my_test"
doc-scrape-examples = true
```
chore: Upgrade dependencies
This upgrades several dependencies to the latest "major" release. The original intent was just to get onto the latest snapbox but I noticed several others that could be updated and thought "why not".
- `snapbox` broke compatibility on less used APIs
- Its unclear from the docs if `miow` or `remove_dir_all` even broke compatibility
I did not touch `mdman` as that has several large, stale deps
