Forbid setting `RUSTC_BOOTSTRAP` from a build script on stable
Instead, recommend `RUSTC_BOOTSTRAP=crate_name`. If cargo is using a nightly toolchain, or if RUSTC_BOOTSTRAP was set in *cargo*'s build environment, the error is downgraded to a warning, since the variable won't affect the build.
This is mostly the same as suggested in https://github.com/rust-lang/cargo/issues/7088#issuecomment-713867773, except that `RUSTC_BOOTSTRAP=` values other than 1 are treated the same as `RUSTC_BOOTSTRAP=1`. My reasoning was that https://github.com/rust-lang/rust/pull/77802 is now on 1.50 stable, so some crates may have started using it, and I would still prefer not to give hard errors when there's no workaround.
Closes https://github.com/rust-lang/cargo/issues/7088.
r? `@joshtriplett`
Throw error if CARGO_TARGET_DIR is an empty string
This pull request makes the target dir to be target/ if `CARGO_TARGET_DIR` is `` with spaces trimmed and not delete the current project.
Fixes: #8866
`nightly_features_allowed()` is no longer doing any work, so it can be
accessed directly. This also renames the `enable_nightly_features` field
to `nightly_features_allowed`.
Previously, since `ENABLE_NIGHTLY_FEATURES` and
`NIGHTLY_FEATURES_ENABLED` were thread locals, reading them in any other
thread would always say nightly features were disabled. Now, they are
tied to the `Context` itself, so it is both more clear how the variables
are being set and fixes the behavior within work threads.
Note that `Context` is not thread-safe, so this passes a boolean through
to `BuildOutput::parse`.
This follows the convention of `lto` and `debug` that allow `true` for
the highest level, and `false` for disabled.
Signed-off-by: David Calavera <david.calavera@gmail.com>
These tests demonstrate the current failure mode around
overlapping env keys and inner structs. To some extent this
is a limitation of mapping on to environment variables with
an underscore as both the namespace separator and the
substitute for dashes in flag names in that the mapping is
not strictly one-to-one.
The current behavior, with the default-false workaround in place,
is not able to identify extra members of the `unstable` table, so
it can't error on unexpected members.
I'll add this test back in with a Deserializer refactor to clean up
the extra logic added to CliUnstable.
Tests are currently failing, looks like there's something in the
Deserializer impl that's forcing field-missing errors even when
the serde `default` annotation is applied.
Obviously this only works with nightlies and all
that, but if you're e.g. testing resolver v2, want
to always have Ztiming on in your workspace, or
something like that, this makes it easier to do.
With `opt-level = "3"` this previously said:
must be an integer, `z`, or `s`, but found: 3 for ...
The error message doesn't make that super clear.
This should now be a bit more clear.
Fixes#8234
There's an existing bug (#7782) in Cargo which exacerbates the issue
here but in general having a stack of errors is a bit easier to read and
work with than having a big long error message.
The `anyhow` crate interoperates with the `std::error::Error` trait
rather than a custom `Fail` trait, and this is the general trend of
error handling in Rust as well.
Note that this is mostly mechanical (sed) and intended to get the test
suite passing. As usual there's still more idiomatic cleanup that can
happen, but that's left to later commits.
Rewrite helpers like `get_bool` to use `get::<Option<Value<bool>>>`
instead of duplicating the logic that's already with the typed access of
configuration. This is more along the effort to centralize all
deserialization of configuration into typed values instead of using
ad-hoc accessors in a number of locations.
Also make it a little less allocation-heavy by tweaking the API to
encourage incremental building of the key and incremental destruction as
we walk throughout the configuration tree.
