about summary refs log tree commit diff
path: root/src/bootstrap
AgeCommit message (Collapse)AuthorLines
2020-06-14Auto merge of #73232 - RalfJung:miri-no-default, r=Mark-Simulacrumbors-12/+20
x.py: do not build Miri by default on stable/beta Fixes https://github.com/rust-lang/rust/issues/73117 Do I need to do anything to make sure Miri is still built by the tools CI builder? Are there other tools that should be off-by-default? Also, unfortunately the `DEFAULT` associated const has no doc comment, so I have no idea what it does, or why there are semmingly two places where the default build of tools is controlled.
2020-06-13Speed up bootstrap a little.Eric Huss-45/+33
2020-06-13Rollup merge of #73267 - ehuss:cargotest-this-cargo, r=Mark-SimulacrumDylan DPC-1/+2
Use the built cargo for cargotest. cargotest was using the beta (bootstrap) cargo. This changes it so that it will use the locally built cargo. This is intended to provide a sort of smoke test to ensure Cargo is functional. This *shouldn't* have any real impact on the CI build time. The cargotest job also happens to run cargo's testsuite, so it should already be building cargo. Note: This will fail until #73266 is merged.
2020-06-12Remove vestigial CI job msvc-aux.Eric Huss-16/+2
2020-06-12x.py: do not build Miri by defaultRalf Jung-12/+20
2020-06-12Auto merge of #69478 - avr-rust:avr-support-upstream, r=jonas-schievinkbors-1/+1
Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares, or make suggestions on the code patch itself.
2020-06-11Use the built cargo for cargotest.Eric Huss-1/+2
2020-06-11Rollup merge of #73097 - Mark-Simulacrum:clippy-fail, r=oli-obkDylan DPC-1/+1
Try_run must only be used if toolstate is populated Clippy's tests were failing the build, but that failure was ignored in favor of checking toolstate. This is the correct behavior for toolstate-checked tools, but Clippy no longer updates its toolstate status as it should always build. The previous PR of this kind didn't catch this as I expected x.py failures to always lead to a non-successful build in CI, but that's not the case specifically for tool testing.
2020-06-11Move shipped MinGW linker to self-contained dirMateusz Mikuła-1/+6
2020-06-11Move some libs to self-contained directoryMateusz Mikuła-9/+28
2020-06-11Use enum to distinguish dependency typeMateusz Mikuła-26/+54
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-11Enable LLVM zlib when building LLDJethro Beekman-1/+8
2020-06-10x.py: with --json-output, forward cargo's JSONRalf Jung-1/+7
2020-06-09Add a disabled builder for riscv64 emulated testsTom Eccles-0/+2
This will run all tests for `riscv64gc-unknown-linux-gnu` in a QEMU instance. This is based upon the armhf QEMU test image.
2020-06-09Implement new gdb/lldb pretty-printersortem-3/+5
Replace old GDB and LLDB pretty-printers with new ones which were originally written for IntelliJ Rust. New LLDB pretty-printers support synthetic children. New GDB/LLDB pretty-printers support all Rust types supported by old pretty-printers, and also support: Rc, Arc, Cell, Ref, RefCell, RefMut, HashMap, HashSet.
2020-06-09[AVR] Add AVR platform supportJake Goulding-1/+1
2020-06-07Try_run must only be used if toolstate is populatedMark Rousskov-1/+1
Clippy's tests were failing the build, but that failure was ignored in favor of checking toolstate. This is the correct behavior for toolstate-checked tools, but Clippy no longer updates its toolstate status as it should always build.
2020-06-07Enable LVI hardening for x86_64-fortanix-unknown-sgxJethro Beekman-1/+3
2020-06-07Rollup merge of #72993 - cuviper:beta-number, r=Mark-SimulacrumDylan DPC-18/+4
Count the beta prerelease number just from master We were computing a merge-base between the remote beta and master branches, but this was giving incorrect answers for the first beta if the remote hadn't been pushed yet. For instance, `1.45.0-beta.3359` corresponds to the number of merges since the 1.44 beta, but we really want just `.1` for the sole 1.45 beta promotion merge. We don't really need to query the remote beta at all -- `master..HEAD` suffices if we assume that we're on the intended beta branch already.
2020-06-04Count the beta prerelease number just from masterJosh Stone-18/+4
We were computing a merge-base between the remote beta and master branches, but this was giving incorrect answers for the first beta if the remote hadn't been pushed yet. For instance, `1.45.0-beta.3359` corresponds to the number of merges since the 1.44 beta, but we really want just `.1` for the sole 1.45 beta promotion merge. We don't really need to query the remote beta at all -- `master..HEAD` suffices if we assume that we're on the intended beta branch already.
2020-06-03Bump to 1.46Mark Rousskov-1/+1
2020-06-02Auto merge of #72672 - seritools:remote-test-windows, r=Mark-Simulacrumbors-1/+1
Make remote-test-client and remote-test-server compatible with windows `compiletest` and `remote-test-client`: The command line for `remote-test-client` was changed slightly to allow cross-platform compatible paths. The old way of supplying the support libs was by joining their paths with the executable path with `:`. This caused Windows-style paths to be split after the directory letter. Now, the number of support libs is provided as a parameter as well, and the support lib paths are split off from the regular args in the client. `remote-test-server`: - Marked Unix-only parts as such and implemented Windows alternatives - On Windows `LD_LIBRARY_PATH` doesn't exist. Libraries are loaded from `PATH` though, so that's the way around it. - Tiny cleanup: `Command::args`/`envs` instead of manually looping over them - The temp path for Windows has to be set via environment variable, since there isn't a global temp directory that would work on every machine (as a static string)
2020-06-01bump Miri, update for cargo-miri being a separate projectRalf Jung-5/+16
2020-05-31Make `remote-test-client` work as cargo runner againDennis Duda-1/+1
Since cargo appends executable/args, the support_lib count parameter has to come first.
2020-05-30Rollup merge of #72728 - o01eg:fix-72661, r=Mark-SimulacrumRalf Jung-7/+30
Make bootstrap aware of relative libdir in stage0 compiler Follows up #72692 Fixes #72661
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-29Get libdir from stage0 compilerO01eg-4/+21
2020-05-29Fix lld detection if stage0 rustc built with custom libdirO01eg-7/+13
2020-05-29Auto merge of #72671 - flip1995:clippyup, r=Xanewokbors-0/+4
Update Clippy, RLS, and rustfmt r? @Dylan-DPC This makes Clippy test-pass again: 3089c3b Otherwise this includes bugfixes and a few new lints. Fixes #72231 Fixes #72232
2020-05-28Set CFG_RELEASE for tools in bootstrap/tool.rsIgor Matuszewski-0/+4
Since rustc-ap-* v659 we now need to set CFG_RELEASE for rustc-ap-rustc_attr for `#[cfg(version(...))]` to work. Co-authored-by: Eric Huss <ehuss@users.noreply.github.com>
2020-05-27Clippy should always buildMark Rousskov-34/+26
This just unwraps clippy's build step instead of skipping tests if clippy didn't build. This matches e.g. cargo's behavior and seems more correct, as we always expect clippy to successfully build.
2020-05-25Remove legacy InnoSetup GUI installerChris Denton-21/+0
On Windows the InnoSetup installer was superseded by the MSI installer. It's no longer needed.
2020-05-24bootstrap: propagate test-args to miri and clippy test suitesRalf Jung-0/+4
2020-05-22Rollup merge of #72453 - dtolnay:open, r=Mark-SimulacrumDylan DPC-3/+73
Add flag to open docs: x.py doc --open This aligns with Cargo's flag `cargo doc --open`. Tested with: ```bash # opens doc/index.html x.py doc --stage 0 --open x.py doc --stage 0 --open src/doc # opens doc/book/index.html x.py doc --stage 0 --open src/doc/book # opens doc/std/index.html x.py doc --stage 0 --open src/libstd # opens doc/proc_macro/index.html x.py doc --stage 0 --open src/libproc_macro # opens both x.py doc --stage 0 --open src/libstd src/libproc_macro ```
2020-05-22Report error from opener in bootstrapDavid Tolnay-4/+4
On my machine, an error looks like: Finished release [optimized] target(s) in 0.29s Opening doc /git/rust/build/x86_64-unknown-linux-gnu/doc/std/index.html command 'xdg-open (internal)' did not execute successfully; exit code: 4 command stderr: gio: file:///git/rust/build/x86_64-unknown-linux-gnu/doc/std/index.html: Error when getting information for file “/git/rust/build/x86_64-unknown-linux-gnu/doc/std/index.html”: No such file or directory Build completed successfully in 0:00:08
2020-05-22Auto merge of #72000 - cuviper:dist-llvm, r=Mark-Simulacrumbors-20/+30
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-21Add flag to open docs: x.py doc --openDavid Tolnay-3/+73
Tested with: # opens doc/index.html x.py doc --stage 0 --open x.py doc --stage 0 --open src/doc # opens doc/book/index.html x.py doc --stage 0 --open src/doc/book # opens doc/std/index.html x.py doc --stage 0 --open src/libstd # opens doc/proc_macro/index.html x.py doc --stage 0 --open src/libproc_macro # opens both x.py doc --stage 0 --open src/libstd src/libproc_macro
2020-05-20Move the target libLLVM to llvm-tools-previewJosh Stone-20/+30
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-20Auto merge of #67759 - nikic:llvm-10, r=Mark-Simulacrumbors-0/+4
Update to LLVM 10 LLVM 10 is going to be branched soon, so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted, but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert, there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135, https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.
2020-05-20Set CMAKE_CXX_STANDARD when compiling LLDNikita Popov-0/+4
2020-05-20Auto merge of #71769 - petrochenkov:crto, r=cuviperbors-6/+7
linker: More systematic handling of CRT objects Document which kinds of `crt0.o`-like objects we link and in which cases, discovering bugs in process. `src/librustc_target/spec/crt_objects.rs` is the place to start reading from. This PR also automatically contains half of the `-static-pie` support (https://github.com/rust-lang/rust/pull/70740), because that's one of the six cases that we need to consider when linking CRT objects. This is a breaking change for custom target specifications that specify CRT objects. Closes https://github.com/rust-lang/rust/issues/30868
2020-05-17bootstrap: fix typoRalf Jung-1/+1
2020-05-15Rollup merge of #72172 - Mark-Simulacrum:check-no-stage, r=alexcrichtonDylan DPC-0/+14
Forbid stage arguments to check Users generally expect that check builds are fast, and that's only true in stage 0 (stages beyond that need us to build a compiler, which is slow). Closes #69337 r? @alexcrichton
2020-05-15Rollup merge of #72146 - Mark-Simulacrum:separate-std-asserts, r=alexcrichtonDylan DPC-1/+14
Provide separate option for std debug asserts On local one-off benchmarking of libcore metadata-only, debug asserts in std are a significant hit (15s to 20s). Provide an option for compiler developers to disable them. A build with a nightly compiler is around 10s, for reference.
2020-05-14Rollup merge of #71964 - jcotton42:bootstrap_decode_none_windows, ↵Ralf Jung-3/+6
r=Mark-Simulacrum Fix bootstrap failing on win32 ```powershell python x.py -h # or really any x.py command ``` would fail with ``` info: Downloading and building bootstrap before processing --help command. See src/bootstrap/README.md for help with common commands. Updating only changed submodules Submodules updated in 0.15 seconds Traceback (most recent call last): File "x.py", line 11, in <module> bootstrap.main() File "C:\Users\Joshua\Projects\forks\rust\src\bootstrap\bootstrap.py", line 960, in main bootstrap(help_triggered) File "C:\Users\Joshua\Projects\forks\rust\src\bootstrap\bootstrap.py", line 925, in bootstrap build.build = args.build or build.build_triple() File "C:\Users\Joshua\Projects\forks\rust\src\bootstrap\bootstrap.py", line 731, in build_triple return default_build_triple() File "C:\Users\Joshua\Projects\forks\rust\src\bootstrap\bootstrap.py", line 184, in default_build_triple ostype = require(["uname", "-s"], exit=required).decode(default_encoding) AttributeError: 'NoneType' object has no attribute 'decode' ``` This PR defers the `decode` call until after we're sure `ostype` and `cputype` are not `None`, as they would be on Windows since `uname` doesn't exist
2020-05-14linker: More systematic handling of CRT objectsVadim Petrochenkov-6/+7
2020-05-14Auto merge of #72058 - RalfJung:no-dist-lldb, r=Mark-Simulacrumbors-162/+7
bootstrap: remove lldb dist packaging The lldb-preview rustup package is missing on every single target, and has never been shipped beyond x86_64-apple-darwin. It was removed in #62592 which landed around a year ago, and there's not been demand that we re-enable it since, so we're now removing support entirely to cleanup the code a bit. The hope is that this will also kill the useless "lldb-preview" row on https://rust-lang.github.io/rustup-components-history/.
2020-05-13Forbid stage arguments to checkMark Rousskov-0/+14
Users generally expect that check builds are fast, and that's only true in stage 0 (stages beyond that need us to build a compiler, which is slow).
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-03-01 14:48:17 +0000