Don't give a hard error when the end-user specifies RUSTC_BOOTSTRAP=crate_name
Fixes https://github.com/rust-lang/cargo/issues/9362.
The whole point of https://github.com/rust-lang/rust/pull/77802/ was to allow specifying this granularly, giving a hard error defeats the point.
I didn't know how to check what targets were reverse-dependencies of build.rs, so I just unconditionally use the library name (and give a hard error for anything else, even if it's the name of one of the binaries). End-users can still opt-in with RUSTC_BOOTSTRAP=1, and no public binaries use RUSTC_BOOTSTRAP=1, so I don't think this a big deal in practice.
<details><summary>Script to verify all crates using RUSTC_BOOTSTRAP=1 have a library</summary>
```sh
curl https://pastebin.com/raw/fGQ97xP6 | cut -d / -f1 | grep -v shnatsel | grep -v cargo- | sed 's#-\([0-9]\)#/\1#' | xargs -i curl -s -I -L "https://docs.rs/{}/" -w "%{http_code}\n" -o/dev/null
```
It should output 20 200s in a row.
</details>
r? `@ehuss` cc `@mark-simulacrum`
I don't know what cargo's policy is for backports, but this should be backported to 1.52.
Fix#9350 (cargo build -Z help is missing options)
> Do not merge yet, some options are still undocumented.
Fix#9350 (cargo build -Z help is missing options)
Add a procedural macro to declare `CliUnstable` struct and provide help messages instead of hard-coding help in `src/bin/cargo/cli.rs`
> Flags documentation: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html
Feedback welcome
> Do not merge yet, some options are still undocumented.
Fix#9350 (cargo build -Z help is missing options)
Add a procedural macro to declare `CliUnstable` struct and provide help messages instead of hard-coding help in `src/bin/cargo/cli.rs`
> Flags documentation: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html
Feedback welcome
This commit fixes an issue where the order of packages serialized into a
lock file differs on stable vs nightly. This is due to a bug introduced
in #9133 where a manual `Ord` implementation was replaced with a
`#[derive]`'d one. This was an unintended consequence of #9133 and means
that the same lock file produced by two different versions of Cargo only
differs in what order items are serialized.
With #9133 being reverted soon on the current beta channel this is
intended to be the nightly fix for #9334. This will hopefully mean that
those projects which don't build with beta/nightly will remain
unaffected, and those affected on beta/nightly will need to switch to
the new nightly ordering when it's published (which matches the current
stable). The reverted beta will match this ordering as well.
Closes#9334
Handle man pages better on Windows.
If a user has `man` installed on Windows via msys/mingw/etc, then `cargo help <subcommand>` would fail with `No manual entry for C:\Users\User\AppData\Local\Temp\cargo-manlSKwTQ`. This is because the cygwin universe does not handle windows-style paths and does not auto-translate in this scenario.
The solution here is to run the command from within the temp directory and use a relative path which *should* work on all platforms and environments. I tested on windows (powershell, cmd, and mingw), macos, and linux.
Fixes#9197
Don't re-use rustc cache when RUSTC_WRAPPER changes
We cache initial `rustc --version` invocations, to speed up noop builds.
We check the mtime of `rustc` to bust the cache if the complier changed.
However, before this PR, we didn't look at mtimes of `RUSTC_WRAPPER` /
`RUSTC_WORKSPACE_WRAPPER`, so we could've re-use old cache with new
wrapper.
This doesn't work because it uses the name of the build script, which is
always build_script_build. I'm not sure what to change it to - the name
of the library crate could be different than the name of the package,
and there could be multiple different crates being compiled in the same
package.
refactor: remove `CargoResultExt`
All `chain_err` -> `with_context` are done by IDE refactoring.
- Remove `CargoResultExt`.
- Call `format!` instead of `anyhow::format_err!` to reduce unnecessary macro expansions.
e870eac996/src/cargo/util/errors.rs (L12-L18)
Track "CARGO" in environment fingerprint.
There is an issue where if a package includes an `env!("CARGO")`, that value is not tracked in the fingerprint. If different cargos are used, it will not rebuild. This changes it so that the path to cargo will be tracked in the fingerprint if the CARGO env var is in the dep-info file.
This came up with rust's build system where it [tracks the env](60158f4a7c/src/bootstrap/config.rs (L574)). If you build rust once, and then change the `cargo` value in `config.toml` and try building again, it would not pick up the change which caused me some confusion.
In theory, cargo could fingerprint this every time, but I figure that could be disruptive and trigger needlessly in some situations.
This diff is a little bigger than I would like for such an obscure case. As an alternative, I think rustbuild could just print `cargo:rerun-if-env-changed=CARGO`, but I figure this could potentially be useful for other projects.
We cache initial `rustc --version` invocations, to speed up noop builds.
We check the mtime of `rustc` to bust the cache if the complier changed.
However, before this PR, we didn't look at mtimes of `RUSTC_WRAPPER` /
`RUSTC_WORKSPACE_WRAPPER`, so we could've re-use old cache with new
wrapper.
Update clippy lint allow set.
This updates the clippy lints to default allow. We would prefer not to take clippy lint PRs at this time as there are a number of false positives and subjective style changes that we would rather not review.
I left a couple lints as `warn` that I have found useful when refactoring.
Add -Zallow-features to match rustc's -Z
This PR implements the `-Zallow-features` permanently-unstable feature flag that explicitly enumerates which unstable features are allowed (assuming unstable features are permitted in the first place). This mirrors the `-Zallow-features` flag of `rustc` which serves the same purpose for `rustc` features:
5fe790e3c4/compiler/rustc_session/src/options.rs (L856-L857)
This flag makes it easier to beta-test unstable features "safely" by ensuring that only a single unstable feature is used if you only have control over build system, and not the source code that developers may end up using, as discussed in [this internals thread](https://internals.rust-lang.org/t/mechanism-for-beta-testing-unstable-features/14280).
If this weren't the case, a user that compiled, and then re-ran cargo
with a particular set of allowed features would not see any breakage
even if other unstable features were used.
The downside of this is that changing allow-features causes a full
re-compile, but that still _seems_ like the right thing to do.
