-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
etc: add RUSTC_BOOTSTRAP
to rust-analyzer config
#113906
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
(rustbot has picked a reviewer for you, use r? to override) |
rustbot
added
the
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
label
Jul 20, 2023
This comment has been minimized.
This comment has been minimized.
notriddle
force-pushed
the
notriddle/cargo-extra-env
branch
from
July 20, 2023 23:53
a917eef
to
a62e30e
Compare
Fixes the problem reported in rust-lang#112391 (comment)
rustbot
added
the
T-bootstrap
Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
label
Jul 20, 2023
@bors r+ rollup |
bors
added
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
and removed
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
labels
Jul 31, 2023
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Jul 31, 2023
…v, r=Mark-Simulacrum etc: add `RUSTC_BOOTSTRAP` to rust-analyzer config Fixes the problem reported in rust-lang#112391 (comment)
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Jul 31, 2023
…v, r=Mark-Simulacrum etc: add `RUSTC_BOOTSTRAP` to rust-analyzer config Fixes the problem reported in rust-lang#112391 (comment)
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jul 31, 2023
…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#112858 (Update Android system definitions and add riscv-linux-android as tier 3 target) - rust-lang#113717 (remove repetitive words) - rust-lang#113725 (Move MinGW linker dist option to proper section) - rust-lang#113740 (Update `.gitmodules` to use shallow submodule clones) - rust-lang#113889 (Fix ice tests when librustc-driver is linked dynamically) - rust-lang#113906 (etc: add `RUSTC_BOOTSTRAP` to rust-analyzer config) - rust-lang#113920 (fix(resolve): report unresolved imports firstly) - rust-lang#114111 (Improve test case for experimental API remove_matches) r? `@ghost` `@rustbot` modify labels: rollup
compiler-errors
added a commit
to compiler-errors/rust
that referenced
this pull request
Jan 17, 2024
…-ozkan Consistently unset RUSTC_BOOTSTRAP when compiling bootstrap Since rust-lang#113906, all x.py invocations performed by rust-analyzer have RUSTC_BOOTSTRAP=1 set. This was to fix rust-lang#112391 (comment) — rust-analyzer uses some default cargo from the system when fetching workspace layout, and the standard library uses some unstable cargo feature, so x.py would previously fail if the system toolchain wasn't nightly. https://github.com/rust-lang/rust/blob/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/Cargo.toml#L1 This PR changes x.py to cancel out this RUSTC_BOOTSTRAP=1 when compiling bootstrap. It will only remain set when running the compiled bootstrap executable. This fixes spurious bootstrap rebuilds in the event that a rust-analyzer x.py invocation is alternated with someone running x.py themself on the command line, if any dependency of bootstrap looks at `option_env!("RUSTC_BOOTSTRAP")`, which is the case since rust-lang#119654. **Before:** ```console $ RUSTC_BOOTSTRAP=1 ./x.py check library/core Building bootstrap Compiling proc-macro2 v1.0.76 Compiling quote v1.0.35 Compiling syn v2.0.48 Compiling clap_derive v4.4.7 Compiling serde_derive v1.0.195 Compiling clap v4.4.13 Compiling clap_complete v4.4.6 Compiling build_helper v0.1.0 Compiling bootstrap v0.0.0 Finished dev [unoptimized] target(s) in 6.31s Checking stage0 library artifacts {core} (x86_64-unknown-linux-gnu) Finished release [optimized] target(s) in 0.23s Build completed successfully in 0:00:07 $ ./x.py check library/core Building bootstrap Compiling proc-macro2 v1.0.76 Compiling quote v1.0.35 Compiling syn v2.0.48 Compiling clap_derive v4.4.7 Compiling serde_derive v1.0.195 Compiling clap v4.4.13 Compiling clap_complete v4.4.6 Compiling build_helper v0.1.0 Compiling bootstrap v0.0.0 Finished dev [unoptimized] target(s) in 5.30s Checking stage0 library artifacts {core} (x86_64-unknown-linux-gnu) Finished release [optimized] target(s) in 0.25s Build completed successfully in 0:00:06 ``` **After:** ```console $ RUSTC_BOOTSTRAP=1 ./x.py check library/core Building bootstrap Finished dev [unoptimized] target(s) in 0.06s Checking stage0 library artifacts {core} (x86_64-unknown-linux-gnu) Finished release [optimized] target(s) in 0.14s Build completed successfully in 0:00:01 $ ./x.py check library/core Building bootstrap Finished dev [unoptimized] target(s) in 0.04s Checking stage0 library artifacts {core} (x86_64-unknown-linux-gnu) Finished release [optimized] target(s) in 0.13s Build completed successfully in 0:00:01 ```
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Jan 17, 2024
…-ozkan Consistently unset RUSTC_BOOTSTRAP when compiling bootstrap Since rust-lang#113906, all x.py invocations performed by rust-analyzer have RUSTC_BOOTSTRAP=1 set. This was to fix rust-lang#112391 (comment) — rust-analyzer uses some default cargo from the system when fetching workspace layout, and the standard library uses some unstable cargo feature, so x.py would previously fail if the system toolchain wasn't nightly. https://github.com/rust-lang/rust/blob/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/Cargo.toml#L1 This PR changes x.py to cancel out this RUSTC_BOOTSTRAP=1 when compiling bootstrap. It will only remain set when running the compiled bootstrap executable. This fixes spurious bootstrap rebuilds in the event that a rust-analyzer x.py invocation is alternated with someone running x.py themself on the command line, if any dependency of bootstrap looks at `option_env!("RUSTC_BOOTSTRAP")`, which is the case since rust-lang#119654. **Before:** ```console $ RUSTC_BOOTSTRAP=1 ./x.py check library/core Building bootstrap Compiling proc-macro2 v1.0.76 Compiling quote v1.0.35 Compiling syn v2.0.48 Compiling clap_derive v4.4.7 Compiling serde_derive v1.0.195 Compiling clap v4.4.13 Compiling clap_complete v4.4.6 Compiling build_helper v0.1.0 Compiling bootstrap v0.0.0 Finished dev [unoptimized] target(s) in 6.31s Checking stage0 library artifacts {core} (x86_64-unknown-linux-gnu) Finished release [optimized] target(s) in 0.23s Build completed successfully in 0:00:07 $ ./x.py check library/core Building bootstrap Compiling proc-macro2 v1.0.76 Compiling quote v1.0.35 Compiling syn v2.0.48 Compiling clap_derive v4.4.7 Compiling serde_derive v1.0.195 Compiling clap v4.4.13 Compiling clap_complete v4.4.6 Compiling build_helper v0.1.0 Compiling bootstrap v0.0.0 Finished dev [unoptimized] target(s) in 5.30s Checking stage0 library artifacts {core} (x86_64-unknown-linux-gnu) Finished release [optimized] target(s) in 0.25s Build completed successfully in 0:00:06 ``` **After:** ```console $ RUSTC_BOOTSTRAP=1 ./x.py check library/core Building bootstrap Finished dev [unoptimized] target(s) in 0.06s Checking stage0 library artifacts {core} (x86_64-unknown-linux-gnu) Finished release [optimized] target(s) in 0.14s Build completed successfully in 0:00:01 $ ./x.py check library/core Building bootstrap Finished dev [unoptimized] target(s) in 0.04s Checking stage0 library artifacts {core} (x86_64-unknown-linux-gnu) Finished release [optimized] target(s) in 0.13s Build completed successfully in 0:00:01 ```
compiler-errors
added a commit
to compiler-errors/rust
that referenced
this pull request
Jan 17, 2024
…-ozkan Consistently unset RUSTC_BOOTSTRAP when compiling bootstrap Since rust-lang#113906, all x.py invocations performed by rust-analyzer have RUSTC_BOOTSTRAP=1 set. This was to fix rust-lang#112391 (comment) — rust-analyzer uses some default cargo from the system when fetching workspace layout, and the standard library uses some unstable cargo feature, so x.py would previously fail if the system toolchain wasn't nightly. https://github.com/rust-lang/rust/blob/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/Cargo.toml#L1 This PR changes x.py to cancel out this RUSTC_BOOTSTRAP=1 when compiling bootstrap. It will only remain set when running the compiled bootstrap executable. This fixes spurious bootstrap rebuilds in the event that a rust-analyzer x.py invocation is alternated with someone running x.py themself on the command line, if any dependency of bootstrap looks at `option_env!("RUSTC_BOOTSTRAP")`, which is the case since rust-lang#119654. **Before:** ```console $ RUSTC_BOOTSTRAP=1 ./x.py check library/core Building bootstrap Compiling proc-macro2 v1.0.76 Compiling quote v1.0.35 Compiling syn v2.0.48 Compiling clap_derive v4.4.7 Compiling serde_derive v1.0.195 Compiling clap v4.4.13 Compiling clap_complete v4.4.6 Compiling build_helper v0.1.0 Compiling bootstrap v0.0.0 Finished dev [unoptimized] target(s) in 6.31s Checking stage0 library artifacts {core} (x86_64-unknown-linux-gnu) Finished release [optimized] target(s) in 0.23s Build completed successfully in 0:00:07 $ ./x.py check library/core Building bootstrap Compiling proc-macro2 v1.0.76 Compiling quote v1.0.35 Compiling syn v2.0.48 Compiling clap_derive v4.4.7 Compiling serde_derive v1.0.195 Compiling clap v4.4.13 Compiling clap_complete v4.4.6 Compiling build_helper v0.1.0 Compiling bootstrap v0.0.0 Finished dev [unoptimized] target(s) in 5.30s Checking stage0 library artifacts {core} (x86_64-unknown-linux-gnu) Finished release [optimized] target(s) in 0.25s Build completed successfully in 0:00:06 ``` **After:** ```console $ RUSTC_BOOTSTRAP=1 ./x.py check library/core Building bootstrap Finished dev [unoptimized] target(s) in 0.06s Checking stage0 library artifacts {core} (x86_64-unknown-linux-gnu) Finished release [optimized] target(s) in 0.14s Build completed successfully in 0:00:01 $ ./x.py check library/core Building bootstrap Finished dev [unoptimized] target(s) in 0.04s Checking stage0 library artifacts {core} (x86_64-unknown-linux-gnu) Finished release [optimized] target(s) in 0.13s Build completed successfully in 0:00:01 ```
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Jan 17, 2024
…-ozkan Consistently unset RUSTC_BOOTSTRAP when compiling bootstrap Since rust-lang#113906, all x.py invocations performed by rust-analyzer have RUSTC_BOOTSTRAP=1 set. This was to fix rust-lang#112391 (comment) — rust-analyzer uses some default cargo from the system when fetching workspace layout, and the standard library uses some unstable cargo feature, so x.py would previously fail if the system toolchain wasn't nightly. https://github.com/rust-lang/rust/blob/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/Cargo.toml#L1 This PR changes x.py to cancel out this RUSTC_BOOTSTRAP=1 when compiling bootstrap. It will only remain set when running the compiled bootstrap executable. This fixes spurious bootstrap rebuilds in the event that a rust-analyzer x.py invocation is alternated with someone running x.py themself on the command line, if any dependency of bootstrap looks at `option_env!("RUSTC_BOOTSTRAP")`, which is the case since rust-lang#119654. **Before:** ```console $ RUSTC_BOOTSTRAP=1 ./x.py check library/core Building bootstrap Compiling proc-macro2 v1.0.76 Compiling quote v1.0.35 Compiling syn v2.0.48 Compiling clap_derive v4.4.7 Compiling serde_derive v1.0.195 Compiling clap v4.4.13 Compiling clap_complete v4.4.6 Compiling build_helper v0.1.0 Compiling bootstrap v0.0.0 Finished dev [unoptimized] target(s) in 6.31s Checking stage0 library artifacts {core} (x86_64-unknown-linux-gnu) Finished release [optimized] target(s) in 0.23s Build completed successfully in 0:00:07 $ ./x.py check library/core Building bootstrap Compiling proc-macro2 v1.0.76 Compiling quote v1.0.35 Compiling syn v2.0.48 Compiling clap_derive v4.4.7 Compiling serde_derive v1.0.195 Compiling clap v4.4.13 Compiling clap_complete v4.4.6 Compiling build_helper v0.1.0 Compiling bootstrap v0.0.0 Finished dev [unoptimized] target(s) in 5.30s Checking stage0 library artifacts {core} (x86_64-unknown-linux-gnu) Finished release [optimized] target(s) in 0.25s Build completed successfully in 0:00:06 ``` **After:** ```console $ RUSTC_BOOTSTRAP=1 ./x.py check library/core Building bootstrap Finished dev [unoptimized] target(s) in 0.06s Checking stage0 library artifacts {core} (x86_64-unknown-linux-gnu) Finished release [optimized] target(s) in 0.14s Build completed successfully in 0:00:01 $ ./x.py check library/core Building bootstrap Finished dev [unoptimized] target(s) in 0.04s Checking stage0 library artifacts {core} (x86_64-unknown-linux-gnu) Finished release [optimized] target(s) in 0.13s Build completed successfully in 0:00:01 ```
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jan 18, 2024
Rollup merge of rust-lang#120001 - dtolnay:bootstrapbootstrap, r=onur-ozkan Consistently unset RUSTC_BOOTSTRAP when compiling bootstrap Since rust-lang#113906, all x.py invocations performed by rust-analyzer have RUSTC_BOOTSTRAP=1 set. This was to fix rust-lang#112391 (comment) — rust-analyzer uses some default cargo from the system when fetching workspace layout, and the standard library uses some unstable cargo feature, so x.py would previously fail if the system toolchain wasn't nightly. https://github.com/rust-lang/rust/blob/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/Cargo.toml#L1 This PR changes x.py to cancel out this RUSTC_BOOTSTRAP=1 when compiling bootstrap. It will only remain set when running the compiled bootstrap executable. This fixes spurious bootstrap rebuilds in the event that a rust-analyzer x.py invocation is alternated with someone running x.py themself on the command line, if any dependency of bootstrap looks at `option_env!("RUSTC_BOOTSTRAP")`, which is the case since rust-lang#119654. **Before:** ```console $ RUSTC_BOOTSTRAP=1 ./x.py check library/core Building bootstrap Compiling proc-macro2 v1.0.76 Compiling quote v1.0.35 Compiling syn v2.0.48 Compiling clap_derive v4.4.7 Compiling serde_derive v1.0.195 Compiling clap v4.4.13 Compiling clap_complete v4.4.6 Compiling build_helper v0.1.0 Compiling bootstrap v0.0.0 Finished dev [unoptimized] target(s) in 6.31s Checking stage0 library artifacts {core} (x86_64-unknown-linux-gnu) Finished release [optimized] target(s) in 0.23s Build completed successfully in 0:00:07 $ ./x.py check library/core Building bootstrap Compiling proc-macro2 v1.0.76 Compiling quote v1.0.35 Compiling syn v2.0.48 Compiling clap_derive v4.4.7 Compiling serde_derive v1.0.195 Compiling clap v4.4.13 Compiling clap_complete v4.4.6 Compiling build_helper v0.1.0 Compiling bootstrap v0.0.0 Finished dev [unoptimized] target(s) in 5.30s Checking stage0 library artifacts {core} (x86_64-unknown-linux-gnu) Finished release [optimized] target(s) in 0.25s Build completed successfully in 0:00:06 ``` **After:** ```console $ RUSTC_BOOTSTRAP=1 ./x.py check library/core Building bootstrap Finished dev [unoptimized] target(s) in 0.06s Checking stage0 library artifacts {core} (x86_64-unknown-linux-gnu) Finished release [optimized] target(s) in 0.14s Build completed successfully in 0:00:01 $ ./x.py check library/core Building bootstrap Finished dev [unoptimized] target(s) in 0.04s Checking stage0 library artifacts {core} (x86_64-unknown-linux-gnu) Finished release [optimized] target(s) in 0.13s Build completed successfully in 0:00:01 ```
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
T-bootstrap
Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes the problem reported in #112391 (comment)