-
Notifications
You must be signed in to change notification settings - Fork 13k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow making RUSTC_BOOTSTRAP
conditional on the crate name
#77802
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