this also fixes a bug where bootstrap would try to use the fake `rustc` binary built by bootstrap -
cargo puts it in a different directory when using `cargo run` instead of x.py
Same rationale as https://github.com/rust-lang/rust/pull/76544;
it would be nice to make python entirely optional at some point.
This also removes $ROOT as an option for the build directory; I haven't been using it, and like Alex
said in https://github.com/rust-lang/rust/pull/76544#discussion_r488248930 it seems like a
misfeature.
This allows running `cargo run` from src/bootstrap, although that still gives
lots of compile errors if you don't use the beta toolchain.
rustbuild: support RelWithDebInfo for lld
r? ``@alexcrichton``
LLVM has flags that control the level of debuginfo generated when building via rustbuild. Since LLD is built separately, it currently has no way of generating any debuginfo. This change re-uses the same flags as LLVM for LLD to ensure it has the same level of debuginfo generated as LLVM.
The majority of the code is only used by either rustbuild or
rustc_llvm's build script. Rust_build is compiled once for rustbuild and
once for every stage. This means that the majority of the code in this
crate is needlessly compiled multiple times. By moving only the code
actually used by the respective crates to rustbuild and rustc_llvm's
build script, this needless duplicate compilation is avoided.
Enable conditional compilation checking on the Rust codebase
This pull-request enable conditional compilation checking on every rust project build by the `bootstrap` tool.
To be more specific, this PR only enable well known names checking + extra names (bootstrap, parallel_compiler, ...).
r? `@Mark-Simulacrum`
Remove num_cpus dependency from bootstrap, build-manifest and rustc_s…
…ession
`std::threads::available_parallelism` was stabilized in rust 1.59.
r? ```````````````````````````@Mark-Simulacrum```````````````````````````
Fix a bug in `x.py fmt` that prevents some files being formatted.
If you have a file in the repository root with the same name as a file
somewhere within a directory, the latter currently won't get formatted.
I have experienced this multiple times and not understood what was
happening; I finally figured out the problem today. This commit fixes
the problem.
r? ```@Mark-Simulacrum```
If you have a file in the repository root with the same name as a file
somewhere within a directory, the latter currently won't get formatted.
I have experienced this multiple times and not understood what was
happening; I finally figured out the problem today. This commit fixes
the problem.
First, this reverts the `CFLAGS`/`CXXFLAGS` of #93918. Those flags are
already read by `cc` and populated into `Build` earlier on in the
process. We shouldn't be overriding that based on `CFLAGS`, since `cc`
also respects overrides like `CFLAGS_{TARGET}` and `HOST_CFLAGS`, which
we want to take into account.
Second, this adds the same capability to specify target-specific
versions of `LDFLAGS` as we have through `cc` for the `C*` flags:
https://github.com/alexcrichton/cc-rs#external-configuration-via-environment-variables
Note that this also necessitated an update to compiletest to treat
CXXFLAGS separately from CFLAGS.
Use the first codegen backend in the config.toml as default
It is currently hard coded to llvm if enabled and cranelift otherwise.
This made some sense when cranelift was the only alternative codegen
backend. Since the introduction of the gcc backend this doesn't make
much sense anymore. Before this PR bootstrapping rustc using a backend
other than llvm or cranelift required changing the source of
rustc_interface. With this PR it becomes a matter of putting the right
backend as first enabled backend in config.toml.
cc ```@antoyo```
It is currently hard coded to llvm if enabled and cranelift otherwise.
This made some sense when cranelift was the only alternative codegen
backend. Since the introduction of the gcc backend this doesn't make
much sense anymore. Before this PR bootstrapping rustc using a backend
other than llvm or cranelift required changing the source of
rustc_interface. With this PR it becomes a matter of putting the right
backend as first enabled backend in config.toml.
Metadata::modified works in all platforms supported by the filetime
crate. This changes brings rustbuild a tiny bit closer towards dropping
the filetime dependency.
adapt static-nobundle test to use llvm-nm
No functional changes intended.
This updates the test case to use llvm-nm instead of the system nm.
This fixes an instance over at the experimental build of rustc with HEAD LLVM:
https://buildkite.com/llvm-project/rust-llvm-integrate-prototype/builds/8380#ef6f41b5-8595-49a6-be37-0eff80e0ccb5
It is related to https://github.com/rust-lang/rust/pull/94001.
The issue is that this test uses the system nm, which may not be recent
enough to understand the update to uwtable. This replaces the test to
use the llvm-nm that should be recent enough (consistent with the LLVM
sources we use to build rustc).
bootstrap: tidy up flag handling for llvm build
This tidies up the logic in `src/bootstrap/native.rs` such that:
- `CMAKE_*_LINKER_FLAGS` is not overridden if we add to it twice.
- `CMAKE_*_FLAGS` also include the standard `*FLAGS` environment
variables, which CMake respects when we _don't_ set `CMAKE_*_FLAGS`.
- `llvm.ldflags` from `config.toml` appends to the ldflags Rust's
bootstrap logic adds, rather than replacing them.
It also takes a second stab at #89983 by moving `-static-libstdc++` to just be passed as a linker flag, since that's what it is.
Fixes#93880. Fixes#70468. Closes#89983.
Drop time dependency from bootstrap
This was only used for the inclusion of 'current' dates into our manpages, but
it is not clear that this is practically necessary. The manpage is essentially
never updated, and so we can likely afford to keep a manual date in these files.
It also seems possible to just omit it, but that may cause other tools trouble,
so avoid doing that for now.
This is largely done to reduce bootstrap complexity; the time crate is not particularly
small and in #92480 would have started pulling in num-threads, which does runtime
thread count detection. I would prefer to avoid that, so filing this to just drop the nearly
unused dependency entirely.
r? `@pietroalbini`
Rollup of 9 pull requests
Successful merges:
- #89926 (make `Instant::{duration_since, elapsed, sub}` saturating and remove workarounds)
- #90532 (More informative error message for E0015)
- #93810 (Improve chalk integration)
- #93851 (More practical examples for `Option::and_then` & `Result::and_then`)
- #93885 (bootstrap.py: Suggest disabling download-ci-llvm option if url fails to download)
- #93886 (Stabilise inherent_ascii_escape (FCP in #77174))
- #93930 (add link to format_args! when mention it in docs)
- #93936 (Couple of driver cleanups)
- #93944 (Don't relabel to a team if there is already a team label)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
bootstrap.py: Suggest disabling download-ci-llvm option if url fails to download
I got an error when trying to build the compiler using an old commit, and it turns out it was because the option `download-ci-llvm` was implicitly set to true. So this pull request tries to add a help message for other people that may run into the same problem.
To reproduce my error:
```
git checkout 8d7707f3c4f72e6eb334d897354beca692b265d1
./x.py test
[...]
spurious failure, trying again
downloading https://ci-artifacts.rust-lang.org/rustc-builds/db002a06ae9154a35d410550bc5132df883d7baa/rust-dev-nightly-x86_64-unknown-linux-gnu.tar.xz
curl: (22) The requested URL returned error: 404
failed to run: curl -# -y 30 -Y 10 --connect-timeout 30 --retry 3 -Sf -o /tmp/tmp8g13rb4n https://ci-artifacts.rust-lang.org/rustc-builds/db002a06ae9154a35d410550bc5132df883d7baa/rust-dev-nightly-x86_64-unknown-linux-gnu.tar.xz
Build completed unsuccessfully in 0:00:46
```
This is my `config.toml`:
```
# Includes one of the default files in src/bootstrap/defaults
profile = "compiler"
changelog-seen = 2
[rust]
debug = true
```
To reproduce an error with this branch:
Change line 618 of bootstrap.py to
```
url = "rustc-builds-error404/{}".format(llvm_sha)
```
Delete llvm and cached tarball, and set `llvm.download-ci-llvm=true` in config.toml.
```
./x.py test
[...]
spurious failure, trying again
downloading https://ci-artifacts.rust-lang.org/rustc-builds-error404/719b04ca99be0c78e09a8ec5e2eda082a5d8ccae/rust-dev-nightly-x86_64-unknown-linux-gnu.tar.xz
curl: (22) The requested URL returned error: 404
failed to run: curl -# -y 30 -Y 10 --connect-timeout 30 --retry 3 -Sf -o /tmp/tmpesl1ydvo https://ci-artifacts.rust-lang.org/rustc-builds-error404/719b04ca99be0c78e09a8ec5e2eda082a5d8ccae/rust-dev-nightly-x86_64-unknown-linux-gnu.tar.xz
error: failed to download llvm from ci
help: old builds get deleted after a certain time
help: if trying to compile an old commit of rustc, disable `download-ci-llvm` in config.toml:
[llvm]
download-ci-llvm = false
Build completed unsuccessfully in 0:00:01
```
Regarding the implementation, I expected to be able to use a try/catch block in `_download_ci_llvm`, but the `run` function calls `sys.exit` instead of raising an exception so that's not possible. Also, suggestions for better wording of the help message are welcome.
This tidies up the logic in `src/bootstrap/native.rs` such that:
- `CMAKE_*_LINKER_FLAGS` is not overridden if we add to it twice.
- `CMAKE_*_FLAGS` also include the standard `*FLAGS` environment
variables, which CMake respects when we _don't_ set `CMAKE_*_FLAGS`.
- `llvm.ldflags` from `config.toml` appends to the ldflags Rust's
bootstrap logic adds, rather than replacing them.
Fixes#93880.
Support custom options for LLVM build
The LLVM build has a lot of options that rustbuild doesn't need to know about. We should allow the user to customize the LLVM build directly.
Here are some [example customizations][recipe] we'd like to do.
[recipe]: 90105e5e4e/recipes/contrib/clang_toolchain.py (579)
Lazy type-alias-impl-trait
Previously opaque types were processed by
1. replacing all mentions of them with inference variables
2. memorizing these inference variables in a side-table
3. at the end of typeck, resolve the inference variables in the side table and use the resolved type as the hidden type of the opaque type
This worked okayish for `impl Trait` in return position, but required lots of roundabout type inference hacks and processing.
This PR instead stops this process of replacing opaque types with inference variables, and just keeps the opaque types around.
Whenever an opaque type `O` is compared with another type `T`, we make the comparison succeed and record `T` as the hidden type. If `O` is compared to `U` while there is a recorded hidden type for it, we grab the recorded type (`T`) and compare that against `U`. This makes implementing
* https://github.com/rust-lang/rfcs/pull/2515
much simpler (previous attempts on the inference based scheme were very prone to ICEs and general misbehaviour that was not explainable except by random implementation defined oddities).
r? `@nikomatsakis`
fixes#93411fixes#88236
This was only used for the inclusion of 'current' dates into our manpages, but
it is not clear that this is practically necessary. The manpage is essentially
never updated, and so we can likely afford to keep a manual date in these files.
It also seems possible to just omit it, but that may cause other tools trouble,
so avoid doing that for now.
bootstrap: prefer using '--config' over 'RUST_BOOTSTRAP_CONFIG'
Signed-off-by: Muhammad Falak R Wani <falakreyaz@gmail.com>
Closes: #93725
Rleated: #92260
Rerun bootstrap's build script when RUSTC changes
Previously, rustbuild would give strange errors if you tried to reuse the same build directory under two names:
```
$ mkdir tmp && cd tmp
$ ../x.py check
Building rustbuild
Finished dev [unoptimized] target(s) in 35.27s
Checking stage0 std artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
^C
$ cd ..
$ mv tmp/build build
$ ./x.py check
Building rustbuild
Compiling bootstrap v0.0.0 (/home/jnelson/rust-lang/rust/src/bootstrap)
Finished dev [unoptimized] target(s) in 11.18s
failed to execute command: "/home/jnelson/rust-lang/rust/tmp/build/x86_64-unknown-linux-gnu/stage0/bin/rustc" "--target" "x86_64-unknown-linux-gnu" "--print" "target-libdir"
error: No such file or directory (os error 2)
```
This fixes the error. Reusing the same build directory is useful if you want to test path-related things in
bootstrap itself, without having to recompile it each time.
For good measure, this also reruns the build script when PATH changes.