about summary refs log tree commit diff
path: root/src/bootstrap/compile.rs
AgeCommit message (Collapse)AuthorLines
2020-10-26Add support for using cg_clif to bootstrap rustcbjorn3-0/+165
2020-10-11bootstrap: only use compiler-builtins-c if they existGeorge Burgess IV-5/+5
The assignment of `features` above was added in rust-lang#60981, but never used. Presumably the intent was to replace the string literal here with it. While I'm in the area, `compiler_builtins_c_feature` doesn't need to be a `String`.
2020-09-23Remove warning about possible future deprecationDylan MacKenzie-4/+0
2020-09-23Add `keep-stage-std` to `x.py`Dylan MacKenzie-1/+8
This keeps only the `std` artifacts compiled by the given stage, not the compiler. This is useful when working on the latter stages of the compiler in tandem with the standard library, since you don't have to rebuild the *entire* compiler when the standard library changes.
2020-09-12Set link-shared if LLVM ThinLTO is enabled in config.rsMark Rousskov-1/+1
This avoids missing a shared build when uplifting LLVM artifacts into the sysroot. We were already producing a shared link anyway, though, so this is not a visible change from the end user's perspective.
2020-09-11Remove host parameter from step configurationsMark Rousskov-3/+3
rustc is a natively cross-compiling compiler, and generally none of our steps should care whether they are using a compiler built of triple A or B, just the --target directive being passed to the running compiler. e.g., when building for some target C, you don't generally want to build two stds: one with a host A compiler and the other with a host B compiler. Just one std is sufficient.
2020-09-09Move `rustllvm` into `rustc_llvm`Vadim Petrochenkov-2/+2
2020-08-30cleanup: Remove duplicate library names from `Cargo.toml`sVadim Petrochenkov-1/+1
2020-08-30mv compiler to compiler/mark-2/+2
2020-07-27Don't build rustc without stdJoshua Nelson-2/+2
- Set rustc to build only when explicitly asked for This allows building the stage2 rustc artifacts, which nothing depends on. Previously the behavior was as follows (where stageN <-> stage(N-1) artifacts, except for stage0 libstd): - `x.py build --stage 0`: - stage0 libstd - stage1 rustc (but without putting rustc in stage0/) This leaves you without any rustc at all except for the beta compiler (https://github.com/rust-lang/rust/issues/73519). This is never what you want. - `x.py build --stage 1`: - stage0 libstd - stage1 rustc - stage1 libstd - stage1 rustdoc - stage2 rustc This leaves you with a broken stage2 rustc which doesn't even have libcore and is effectively useless. Additionally, it compiles rustc twice, which is not normally what you want. - `x.py build --stage 2`: - stage0 libstd - stage1 rustc - stage1 libstd - stage2 rustc - stage2 rustdoc and tools This builds all tools in release mode. This is the correct usage for CI, but takes far to long for development. Now the behavior is as follows: - `x.py build --stage 0`: - stage0 libstd This is suitable for contributors only working on the standard library, as it means rustc never has to be compiled. - `x.py build --stage 1`: - stage0 libstd - stage1 rustc - stage1 libstd - stage1 rustdoc This is suitable for contributors working on the compiler. It ensures that you have a working rustc and libstd without having to pass `src/libstd` in addition. - `x.py build --stage 2`: - stage0 libstd - stage1 rustc - stage1 libstd - stage2 rustc - stage2 libstd - stage2 rustdoc This is suitable for debugging errors which only appear with the stage2 compiler. - `x.py build --stage 2 src/libstd src/rustc` - stage0 libstd - stage1 rustc - stage1 libstd - stage2 rustc - stage2 libstd - stage2 rustdoc, tools, etc. - stage2 rustc artifacts ('stage3') This is suitable for CI, which wants all tools in release mode. However, most of the use cases for this should use `x.py dist` instead, which builds all the tools without each having to be named individually.
2020-07-27mv std libs to library/mark-4/+4
2020-07-17Teach bootstrap about target files vs target triplesJake Goulding-24/+21
`rustc` allows passing in predefined target triples as well as JSON target specification files. This change allows bootstrap to have the first inkling about those differences. This allows building a cross-compiler for an out-of-tree architecture (even though that compiler won't work for other reasons). Even if no one ever uses this functionality, I think the newtype around the `Interned<String>` improves the readability of the code.
2020-07-16apply bootstrap cfgsMark Rousskov-7/+1
2020-07-10Use str::strip* in bootstrapLzu Tao-4/+5
This commit replaces the use of `trim_start_matches` because in `rustc -Vv` output there are no lines starting with multiple "release:".
2020-06-30Auto merge of #73456 - tmiasko:musl-libdir, r=Mark-Simulacrumbors-3/+3
bootstrap: Configurable musl libdir Make it possible to customize the location of musl libdir using musl-libdir in config.toml, e.g., to use lib64 instead of lib.
2020-06-26Rollup merge of #72937 - AdrianCX:master, r=nikomatsakisManish Goregaokar-17/+4
Fortanix SGX target libunwind build process changes Ticket: https://github.com/fortanix/rust-sgx/issues/174 LLVM related changes (merged): https://github.com/rust-lang/llvm-project/pull/57 Description: libunwind changes needed to run code in sgx environment via rust-sgx. Target that uses this in rust: x86_64-fortanix-unknown-sgx. Without this change, rust std for this toolchain is forced to use a precompiled library loaded via environment variable. With this change we act the same as musl target.
2020-06-25Support configurable deny-warnings for all in-tree crates.Eric Huss-5/+5
2020-06-25Fix commentsAdrian Cruceru-0/+7
2020-06-24Update libunwind build process for x86_64-fortanix-unknown-sgx targetAdrian Cruceru-20/+0
2020-06-19Rollup merge of #72999 - mati865:separate-self-contained-dir, r=Mark-SimulacrumRalf Jung-52/+112
Create self-contained directory and move there some of external binaries/libs One of the steps to reach design described in https://github.com/rust-lang/rust/issues/68887#issuecomment-633048380 This PR moves things around and allows link code to handle the new directory structure.
2020-06-18bootstrap: Configurable musl libdirTomasz Miąsko-3/+3
Make it possible to customize the location of musl libdir using musl-libdir in config.toml, e.g., to use lib64 instead of lib.
2020-06-17Auto merge of #69890 - lenary:lenary/riscv-frame-pointers, ↵bors-0/+10
r=hanna-kruppe,Mark-Simulacrum [RISC-V] Do not force frame pointers We have been seeing some very inefficient code that went away when using `-Cforce-frame-pointers=no`. For instance `core::ptr::drop_in_place` at `-Oz` was compiled into a function which consisted entirely of saving registers to the stack, then using the frame pointer to restore the same registers (without any instructions between the prolog and epilog). The RISC-V LLVM backend supports frame pointer elimination, so it makes sense to allow this to happen when using Rust. It's not clear to me that frame pointers have ever been required in the general case. In rust-lang/rust#61675 it was pointed out that this made reassembling stack traces easier, which is true, but there is a code generation option for forcing frame pointers, and I feel the default should not be to require frame pointers, given it demonstrably makes code size worse (around 10% in some embedded applications). The kinds of targets mentioned in rust-lang/rust#61675 are popular, but should not dictate that code generation should be worse for all RISC-V targets, especially as there is a way to use CFI information to reconstruct the stack when the frame pointer is eliminated. It is also a misconception that `fp` is always used for the frame pointer. `fp` is an ABI name for `x8` (aka `s0`), and if no frame pointer is required, `x8` may be used for other callee-saved values. --- I am partly posting this to get feedback from @fintelia who introduced the change to require frame pointers, and @hanna-kruppe who had issues with the original PR. I would understand if we wanted to remove this setting on only a subset of RISC-V targets, but my preference would be to remove this setting everywhere. There are more details on the code size savings seen in Tock here: https://github.com/tock/tock/pull/1660
2020-06-11Move some libs to self-contained directoryMateusz Mikuła-7/+17
2020-06-11Use enum to distinguish dependency typeMateusz Mikuła-20/+32
2020-06-11Move copying of MinGW CRT to the better locationMateusz Mikuła-7/+7
2020-06-11Move copying of self-contained objects to new functionMateusz Mikuła-25/+63
2020-06-10x.py: with --json-output, forward cargo's JSONRalf Jung-1/+7
2020-05-30[RISC-V] Do not force frame pointersSam Elliott-0/+10
We have been seeing some very inefficient code that went away when using `-Cforce-frame-pointers=no`. For instance `core::ptr::drop_in_place` at `-Oz` was compiled into a function which consisted entirely of saving registers to the stack, then using the frame pointer to restore the same registers (without any instructions between the prolog and epilog). The RISC-V LLVM backend supports frame pointer elimination, so it makes sense to allow this to happen when using Rust. It's not clear to me that frame pointers have ever been required in the general case. In rust-lang/rust#61675 it was pointed out that this made reassembling stack traces easier, which is true, but there is a code generation option for forcing frame pointers, and I feel the default should not be to require frame pointers, given it demonstrably makes code size worse (around 10% in some embedded applications). The kinds of targets mentioned in rust-lang/rust#61675 are popular, but should not dictate that code generation should be worse for all RISC-V targets, especially as there is a way to use CFI information to reconstruct the stack when the frame pointer is eliminated. It is also a misconception that `fp` is always used for the frame pointer. `fp` is an ABI name for `x8` (aka `s0`), and if no frame pointer is required, `x8` may be used for other callee-saved values. This commit does ensure that the standard library is built with unwind tables, so that users do not need to rebuild the standard library in order to get a backtrace that includes standard library calls (which is the original reason for forcing frame pointers).
2020-05-22Auto merge of #72000 - cuviper:dist-llvm, r=Mark-Simulacrumbors-1/+2
Move the target libLLVM to llvm-tools-preview For running the compiler, we usually only need LLVM from `$sysroot/lib`, which rustup will make available with `LD_LIBRARY_PATH`. We've also been shipping LLVM in the `$target/lib` directory, which bloats the download and installed size. The only times we do need the latter are for the RPATH of `llvm-tools-preview` binaries, and for linking `rustc-dev` libraries. We'll move it to the `llvm-tools-preview` component directly, and `rustc-dev` will have an implicit dependency on it. Here are the dist sizes that I got before and after this change: llvm-tools-1.45.0-dev-x86_64-unknown-linux-gnu.tar.gz 1.3M 24M llvm-tools-1.45.0-dev-x86_64-unknown-linux-gnu.tar.xz 748K 17M rustc-1.45.0-dev-x86_64-unknown-linux-gnu.tar.gz 83M 61M rustc-1.45.0-dev-x86_64-unknown-linux-gnu.tar.xz 56M 41M The installed size should reduce by exactly one `libLLVM.so` (~70-80M), unless you also install `llvm-tools`, and then it should be identical. Resolves #70838.
2020-05-20Move the target libLLVM to llvm-tools-previewJosh Stone-1/+2
For running the compiler, we usually only need LLVM from `$sysroot/lib`, which rustup will make available with `LD_LIBRARY_PATH`. We've also been shipping LLVM in the `$target/lib` directory, which bloats the download and installed size. The only times we do need the latter are for the RPATH of `llvm-tools-preview` binaries, and for linking `rustc-dev` libraries. We'll move it to the `llvm-tools-preview` component directly, and `rustc-dev` will have an implicit dependency on it. Here are the dist sizes that I got before and after this change: llvm-tools-1.45.0-dev-x86_64-unknown-linux-gnu.tar.gz 1.3M 24M llvm-tools-1.45.0-dev-x86_64-unknown-linux-gnu.tar.xz 748K 17M rustc-1.45.0-dev-x86_64-unknown-linux-gnu.tar.gz 83M 61M rustc-1.45.0-dev-x86_64-unknown-linux-gnu.tar.xz 56M 41M The installed size should reduce by exactly one `libLLVM.so` (~70-80M), unless you also install `llvm-tools`, and then it should be identical.
2020-05-14linker: More systematic handling of CRT objectsVadim Petrochenkov-6/+7
2020-05-02Don't skip building LLVM if already builtMark Rousskov-3/+7
2020-05-02Auto merge of #71716 - alexcrichton:bitcode-follow-up, r=nnethercotebors-3/+3
Rename `bitcode-in-rlib` option to `embed-bitcode` This commit finishes work first pioneered in #70458 and started in #71528. The `-C bitcode-in-rlib` option, which has not yet reached stable, is renamed to `-C embed-bitcode` since that more accurately reflects what it does now anyway. Various tests and such are updated along the way as well. This'll also need to be backported to the beta channel to ensure we don't accidentally stabilize `-Cbitcode-in-rlib` as well.
2020-05-01Rename `bitcode-in-rlib` option to `embed-bitcode`Alex Crichton-3/+3
This commit finishes work first pioneered in #70458 and started in #71528. The `-C bitcode-in-rlib` option, which has not yet reached stable, is renamed to `-C embed-bitcode` since that more accurately reflects what it does now anyway. Various tests and such are updated along the way as well. This'll also need to be backported to the beta channel to ensure we don't accidentally stabilize `-Cbitcode-in-rlib` as well.
2020-04-25Handle build completion message from CargoMark Rousskov-0/+3
This was introduced in the recent bump to 1.43 bootstrap cargo
2020-04-22Build libstd with `-Cbitcode-in-rlib=yes`.Nicholas Nethercote-2/+14
So that the rlibs will work with both LTO and non-LTO builds.
2020-04-11Require compiler-rt root at ../src/llvm-project/compiler-rtLuca Barbieri-0/+2
2020-04-03Auto merge of #70726 - Centril:rollup-zrdkkpt, r=Centrilbors-1/+5
Rollup of 5 pull requests Successful merges: - #68334 (AArch64 bare-metal targets: Build rust-std) - #70224 (Clean up rustdoc js testers) - #70532 (Miri engine: stronger type-based sanity check for assignments) - #70698 (bootstrap: add `--json-output` for rust-analyzer) - #70715 (Fix typo in operands section) Failed merges: r? @ghost
2020-04-02bootstrap: add `--json-output` for rust-analyzerNiko Matsakis-1/+5
2020-04-02Translate the virtual `/rustc/$hash` prefix back to a real directory.Eduard-Mihai Burtescu-1/+25
2020-03-18Revert "Fix missing libLLVM.so in stage0 sysroot."Josh Stone-38/+0
This reverts commit 8b9c5396ca574fad9cc7b51d16c8c96e0ae74632.
2020-03-06fix various typosMatthias Krüger-1/+1
2020-02-03bootstrap: fix clippy warningsMatthias Krüger-10/+10
2020-01-09Add bootstrap step for building sanitizer runtimesTomasz Miąsko-40/+40
2020-01-01Clear out target directory if compiler has changedMark Rousskov-1/+0
Previously, we relied fully on Cargo to detect that the compiler had changed and it needed to rebuild the standard library (or later "components"). This used to not quite be the case prior to moving to LLVM be a separate cargo invocation; subsequent compiles would recompile std and friends if LLVM had changed (#67077 is the PR that changes things here). This PR moves us to clearing out libstd when it is being compiled if the rustc we're using has changed. We fairly harshly limit the cases in which we do this (e.g., ignoring dry run mode, and so forth, as well as rustdoc invocations). This is primarily because when we're not using the compiler directly, so clearing out in other cases is likely to lead to bugs, particularly as our deletion scheme is pretty blunt today (basically removing more than is needed, i.e., not just the rustc artifacts). In practice, this targeted fix does fix the known bug, though it may not fully resolve the problem here. It's also not clear that there is a full fix hiding here that doesn't involve a more major change (like -Zbinary-dep-depinfo was). As a drive-by fix, don't delete the compiler before calling Build::copy, as that also deletes the compiler.
2019-12-22Format the worldMark Rousskov-140/+132
2019-12-18Reenable static linking of libstdc++ on windows-gnuMateusz Mikuła-1/+1
2019-12-11Add comment explaining original `maybe_install_llvm_dylib` callAaron Hill-0/+3
2019-12-11Fix missing libLLVM.so in stage0 sysroot.Aaron Hill-0/+38
When we dynamically link against libLLVM.so (as opposed to statically linking LLVM), we need libLLVM.so to be present in the stage0 sysroot, so that stage1 tools (which are built against the stage0 compiler+sysroot) can see it at build time (when the linker is run) See the comment in the commit for more details
2019-12-11Fix some linking of LLVM's dynamic libraryAlex Crichton-20/+8
Ensure it shows up in the same places it did before so tools can find it at runtime.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-28 06:06:50 +0000