-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Allow making RUSTC_BOOTSTRAP
conditional on the crate name
#77802
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Conversation
f05b859
to
1e21d44
Compare
For ease of review: the important changes are https://github.com/rust-lang/rust/pull/77802/files#diff-1b4d2b405b087e9d70d2bc2b0c24d2fe, the rest of the changes are just passing in the crate name. |
This looks great to me. Once this change is in place, cargo could start catching attempts to set |
Reasonable question. I would generally suggest that compiler is the primary team that needs to approve, and then lang just needs to not object. |
What is the path forward here? It sounds like @joshtriplett and @petrochenkov are in favor of the change - does it need an FCP or something? Should I nominate it for the weekly meeting? |
Thanks for the heads-up. I filed a corresponding Firefox build system bug. |
This comment has been minimized.
This comment has been minimized.
8246bc6
to
2cb2420
Compare
@rfcbot fcp merge |
Team member @petrochenkov has proposed to merge this. The next step is review by the rest of the tagged team members:
No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
@rfcbot reviewed |
@rfcbot reviewed Doing it through the bot so I can say this: I disagree with doing anything here other than forcing distros' hand to adapt to something like rust-lang/compiler-team#350 (comment) which would even allow them to compile some problematic (for now? hopefully there's a transition path...) packages with "unstable The important thing is that they would have control, and have to choose to exert it, over what gets to even use "unstable |
🔔 This is now entering its final comment period, as per the review above. 🔔 |
@eddyb That seems like an orthogonal notion to this issue. Right now, the primary goal is to stop letting Changing the |
The final comment period, with a disposition to merge, as per the review above, is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon. |
The main change is that `UnstableOptions::from_environment` now requires an (optional) crate name. If the crate name is unknown (`None`), then the new feature is not available and you still have to use `RUSTC_BOOTSTRAP=1`. In practice this means the feature is only available for `--crate-name`, not for `#![crate_name]`; I'm interested in supporting the second but I'm not sure how. Other major changes: - Added `Session::is_nightly_build()`, which uses the `crate_name` of the session - Added `nightly_options::match_is_nightly_build`, a convenience method for looking up `--crate-name` from CLI arguments. `Session::is_nightly_build()`should be preferred where possible, since it will take into account `#![crate_name]` (I think). - Added `unstable_features` to `rustdoc::RenderOptions` There is a user-facing change here: things like `RUSTC_BOOTSTRAP=0` no longer active nightly features. In practice this shouldn't be a big deal, since `RUSTC_BOOTSTRAP` is the opposite of stable and everyone uses `RUSTC_BOOTSTRAP=1` anyway. - Add tests Check against `Cheat`, not whether nightly features are allowed. Nightly features are always allowed on the nightly channel. - Only call `is_nightly_build()` once within a function - Use booleans consistently for rustc_incremental Sessions can't be passed through threads, so `read_file` couldn't take a session. To be consistent, also take a boolean in `write_file_header`.
70bfc50
to
622c48e
Compare
@bors r+ |
📌 Commit 622c48e has been approved by |
…as-schievink Rollup of 13 pull requests Successful merges: - rust-lang#77802 (Allow making `RUSTC_BOOTSTRAP` conditional on the crate name) - rust-lang#79004 (Add `--color` support to bootstrap) - rust-lang#79005 (cleanup: Remove `ParseSess::injected_crate_name`) - rust-lang#79016 (Make `_` an expression, to discard values in destructuring assignments) - rust-lang#79019 (astconv: extract closures into a separate trait) - rust-lang#79026 (Implement BTreeMap::retain and BTreeSet::retain) - rust-lang#79031 (Validate that locals have a corresponding `LocalDecl`) - rust-lang#79034 (rustc_resolve: Make `macro_rules` scope chain compression lazy) - rust-lang#79036 (Move Steal to rustc_data_structures.) - rust-lang#79041 (Rename clean::{ItemEnum -> ItemKind}, clean::Item::{inner -> kind}) - rust-lang#79058 (Move likely/unlikely argument outside of invisible unsafe block) - rust-lang#79059 (Print 'checking cranelift artifacts' to easily separate it from other artifacts) - rust-lang#79063 (Update rustfmt to v1.4.26) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Is it expected that crates with a dash in their name as per the crate's Cargo.toml need to be listed in RUSTC_BOOTSTRAP with an underscore instead? |
@glandium I think so, yes - that's the
|
This was the whole point of rust-lang/rust#77802. - Pass `pkg.name()` to `parse()`. This can't pass the `Package` directly because `PackageInner` is an `Rc` and therefore not thread-safe. Note that `pkg_name` was previously a *description* of the package, not the name passed with `--crate-name`.
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 #7088 (comment), except that `RUSTC_BOOTSTRAP=` values other than 1 are treated the same as `RUSTC_BOOTSTRAP=1`. My reasoning was that rust-lang/rust#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 #7088. r? `@joshtriplett`
Don't give a hard error when the end-user specifies RUSTC_BOOTSTRAP=crate_name Fixes #9362. The whole point of rust-lang/rust#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.
Motivation: This came up in the Zulip stream for rust-lang/compiler-team#350.
See also rust-lang/cargo#6608 (comment); this implements rust-lang/cargo#6627.
The goal is for this to eventually allow prohibiting setting
RUSTC_BOOTSTRAP
in build.rs (rust-lang/cargo#7088).User-facing changes
RUSTC_BOOTSTRAP=1
still works; there is no current plan to remove this.RUSTC_BOOTSTRAP=0
no longer activate nightly features. In practice this shouldn't be a big deal, sinceRUSTC_BOOTSTRAP
is the opposite of stable and everyone usesRUSTC_BOOTSTRAP=1
anyway.RUSTC_BOOTSTRAP=x
will enable nightly features only for cratex
.RUSTC_BOOTSTRAP=x,y
will enable nightly features only for cratesx
andy
.Implementation changes
The main change is that
UnstableOptions::from_environment
now requiresan (optional) crate name. If the crate name is unknown (
None
), then the new feature is not available and you still have to useRUSTC_BOOTSTRAP=1
. In practice this means the feature is only available for--crate-name
, not for#![crate_name]
; I'm interested in supporting the second but I'm not sure how.Other major changes:
Session::is_nightly_build()
, which uses thecrate_name
ofthe session
nightly_options::match_is_nightly_build
, a convenience methodfor looking up
--crate-name
from CLI arguments.Session::is_nightly_build()
should be preferred where possible, sinceit will take into account
#![crate_name]
(I think).unstable_features
torustdoc::RenderOptions
I'm not sure whether this counts as T-compiler or T-lang; technically RUSTC_BOOTSTRAP is an implementation detail, but it's been used so much it seems like this counts as a language change too.
r? @joshtriplett
cc @Mark-Simulacrum @hsivonen