about summary refs log tree commit diff
path: root/src/bootstrap
AgeCommit message (Collapse)AuthorLines
2019-05-30Migrate nomicon book to MdBook2Mateusz Mikuła-1/+1
2019-05-30Migrate rustdoc book to MdBook2Mateusz Mikuła-1/+1
2019-05-30Migrate unstable-book to MdBook2Mateusz Mikuła-1/+1
2019-05-30Auto merge of #61212 - alexcrichton:skip-rustc, r=pietroalbinibors-224/+253
ci: Attempt to skip a full rustc compile on dist* Currently when we're preparing cross-compiled compilers it can take quite some time because we have to build the compiler itself three different times. The first is the normal bootstrap, the second is a second build for the build platform, and the third is the actual target architecture compiler. The second compiler was historically built exclusively for procedural macros, and long ago we didn't actually need it. This commit tries out avoiding that second compiled compiler, meaning we only compile rustc for the build platform only once. Some local testing shows that this is promising, but bors is of course the ultimate test!
2019-05-29Rollup merge of #60885 - euclio:strip-synstructure-consts, r=GuillaumeGomezOliver Scherer-1/+1
strip synstructure consts from compiler docs Fixes #60150. Unfortunately this PR depends on the use of the deprecated `--passes` flag in bootstrap to keep the `--strip-hidden` pass while still documenting private items. I've opened #60884 to track stabilization of a new flag that encapsulates this behavior. r? @QuietMisdreavus
2019-05-28Fixup styleAlex Crichton-9/+25
2019-05-28rustbuild: Assert extended builds don't dist too muchAlex Crichton-113/+126
This extends a test in the previous commit to assert that we don't build extra rustc compilers even when the "extended" option is set to true. This involved some internal refactoring to have more judicious usage of `compiler_for`, added in the previous commit, as well. Various `dist::*` targets were refactored to be parameterized with a `Compiler` instead of a `stage`/`host`, and then the various parameters within the `Extended` target were tweaked to ensure that we don't ever accidentally ask for a stage2 build compiler when we're distributing something.
2019-05-28rustbuild: Tweak how stage1 compilers are selectedAlex Crichton-98/+98
This commit furthers the previous one to ensure that we don't build an extra stage of the compiler in CI. A test has been added to rustbuild to ensure that this doesn't regress, and then in debugging this test it was hunted down that the `dist::Std` target was the one erroneously pulling in the wrong compiler. The `dist::Std` step was updated to instead account for the "full bootstrap" or not flag, ensuring that the correct compiler for compiling the final standard library was used. This was another use of the `force_use_stage1` function which was in theory supposed to be pretty central, so existing users were all evaluated and a new function, `Builder::compiler_for`, was introduced. All existing users of `force_use_stage1` have been updated to use `compiler_for`, where the semantics of `compiler_for` are similar to that of `compiler` except that it doesn't guarantee the presence of a sysroot for the arguments passed (as they may be modified). Perhaps one day we can unify `compiler` and `compiler_for`, but the usage of `Builder::compiler` is so ubiquitous it would take quite some time to evaluate whether each one needs the sysroot or not, so it's hoped that can be done in parallel.
2019-05-28Auto merge of #61036 - michaelwoerister:pgo-xlto-test, r=alexcrichtonbors-19/+34
PGO - Add a smoketest for combining PGO with cross-language LTO. This PR - Adds a test making sure that PGO can be combined with cross-language LTO. - Does a little cleanup on how the `pgo-use` flag is handled internally. - Makes the compiler error if the `pgo-use` file given to `rustc` doesn't actually exist. LLVM only gives a warning and then just doesn't do PGO. Clang, on the other hand, does give an error in this case. - Makes the build system also build `compiler-rt` when building LLDB. This way the Clang compiler that we get from building LLDB can perform PGO, which is something that the new test case wants to do. CI compile times shouldn't be affected too much.
2019-05-27Auto merge of #61078 - pietroalbini:nightly-next, r=Centrilbors-1/+1
Bump nightly to 1.37.0 r? @Mark-Simulacrum
2019-05-27Only build clang_rt when RUSTBUILD_FORCE_CLANG_BASED_TESTS is set.Michael Woerister-19/+34
2019-05-27rustbuild: Also build compiler-rt when building LLDB. This allows ↵Michael Woerister-1/+1
clang-based run-make tests to use PGO.
2019-05-26ci: Attempt to skip a full rustc compile on dist*Alex Crichton-15/+15
Currently when we're preparing cross-compiled compilers it can take quite some time because we have to build the compiler itself three different times. The first is the normal bootstrap, the second is a second build for the build platform, and the third is the actual target architecture compiler. The second compiler was historically built exclusively for procedural macros, and long ago we didn't actually need it. This commit tries out avoiding that second compiled compiler, meaning we only compile rustc for the build platform only once. Some local testing shows that this is promising, but bors is of course the ultimate test!
2019-05-25Add clippy and fix commands to x.pyljedrz-17/+105
2019-05-24Auto merge of #60777 - pietroalbini:azure-pipelines, r=alexcrichtonbors-2/+6
Add Azure Pipelines configuration Huge thanks to ＠johnterickson and ＠willsmythe for writing the initial config! :heart: I applied some changes to the initial config and disabled most of the builders since we're not going to run all of them during the initial step for the evaluation. [More details about our plans for the Azure Pipelines evaluation.](https://internals.rust-lang.org/t/update-on-the-ci-investigation/10056) r? ＠alexcrichton ＠kennytm cc ＠rust-lang/infra ＠ethomson ＠rylev
2019-05-24rustbuild: Untie `debuginfo-level-tests` from `debuginfo-level`Vadim Petrochenkov-1/+1
2019-05-24rustbuild: Simplify debuginfo configurationVadim Petrochenkov-68/+48
2019-05-23Auto merge of #60970 - MaulingMonkey:pr-compiletest-cdb-support, r=alexcrichtonbors-6/+2
Add basic CDB support to debuginfo compiletest s, to help catch `*.natvis` regressions, like those fixed in #60687. First draft, feedback welcome. Several Microsoft debuggers (VS, VS Code, WinDbg, CDB, ...) consume the `*.natvis` files we embed into rust `*.pdb` files. While this only tests CDB, that test coverage should help for all of them. # Changes ## src\bootstrap - test.rs: Run CDB debuginfo tests on MSVC targets ## src\test\debuginfo - issue-13213.rs: CDB has trouble with this, skip for now (newly discovered regression?) - pretty-std.rs: Was ignored, re-enable for CDB only to start with, add CDB tests. - should-fail.rs: Add CDB tests. ## src\tools\compiletest: - Added "-cdb" option - Added Mode::DebugInfoCdb ("debuginfo-cdb") - Added run_debuginfo_cdb_test[_no_opt] - Renamed Mode::DebugInfoBoth -> DebugInfoGdbLldb ("debuginfo-gdb+lldb") since it's no longer clear what "Both" means. - Find CDB at the default Win10 SDK install path "C:\Program Files (x86)\Windows Kits\10\Debugger\\*\cdb.exe" - Ignore CDB tests if CDB not found. # Issues - `compute_stamp_hash`: not sure if there's any point in hashing `%ProgramFiles(x86)%` - `OsString` lacks any `*.natvis` entries (would be nice to add in a followup changelist) - DSTs (array/string slices) which work in VS & VS Code fail in CDB. - I've avoided `Mode::DebugInfoAll` as 3 debuggers leads to pow(2,3)=8 possible combinations. # Reference CDB is not part of the base Visual Studio install, but can be added via the Windows 10 SDK: https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk Installing just "Debugging Tools for Windows" is sufficient. CDB appears to already be installed on appveyor CI, where this changelist can find it, based on it's use here: https://github.com/rust-lang/rust/blob/0ffc57311030a1930edfa721fe57d0000a063af4/appveyor.yml#L227 CDB commands and command line reference: https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/debugger-reference
2019-05-23bump nightly to 1.37.0Pietro Albini-1/+1
2019-05-22Bump compiler-builtins to 0.1.15Alex Crichton-1/+28
This commit bumps the `compiler-builtins` dependency to 0.1.15 which expects to have the source for `compiler-rt` provided externally if the `c` feature is enabled. This then plumbs through the necessary support in the build system to ensure that if the `llvm-project` directory is checked out and present that we enable the `c` feature of `compiler-builtins` and compile in all the C intrinsics.
2019-05-21Merge remote-tracking branch 'origin/master' into azure-pipelinesAlex Crichton-5/+23
2019-05-19Add basic CDB support to debuginfo compiletest s, to help catch `*.natvis` ↵MaulingMonkey-6/+2
regressions, like those fixed in #60687. Several Microsoft debuggers (VS, VS Code, WinDbg, CDB, ...) consume the `*.natvis` files we embed into rust `*.pdb` files. While this only tests CDB, that test coverage should help for all of them. CHANGES src\bootstrap - test.rs: Run CDB debuginfo tests on MSVC targets src\test\debuginfo - issue-13213.rs: CDB has trouble with this, skip for now (newly discovered regression?) - pretty-std.rs: Was ignored, re-enable for CDB only to start with, add CDB tests. - should-fail.rs: Add CDB tests. src\tools\compiletest: - Added "-cdb" option - Added Mode::DebugInfoCdb ("debuginfo-cdb") - Added run_debuginfo_cdb_test[_no_opt] - Renamed Mode::DebugInfoBoth -> DebugInfoGdbLldb ("debuginfo-gdb+lldb") since it's no longer clear what "Both" means. - Find CDB at the default Win10 SDK install path "C:\Program Files (x86)\Windows Kits\10\Debugger\*\cdb.exe" - Ignore CDB tests if CDB not found. ISSUES - `compute_stamp_hash`: not sure if there's any point in hashing `%ProgramFiles(x86)%` - `OsString` lacks any `*.natvis` entries (would be nice to add in a followup changelist) - DSTs (array/string slices) which work in VS & VS Code fail in CDB. - I've avoided `Mode::DebugInfoAll` as 3 debuggers leads to pow(2,3)=8 possible combinations. REFERENCE CDB is not part of the base Visual Studio install, but can be added via the Windows 10 SDK: https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk Installing just "Debugging Tools for Windows" is sufficient. CDB appears to already be installed on appveyor CI, where this changelist can find it, based on it's use here: https://github.com/rust-lang/rust/blob/0ffc57311030a1930edfa721fe57d0000a063af4/appveyor.yml#L227 CDB commands and command line reference: https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/debugger-reference
2019-05-18Fix tests not running locallyGuillaume Gomez-1/+1
2019-05-17Update the compiler_builtins crateAlex Crichton-1/+1
This updates to 0.1.13 for `compiler_builtins`, published to fix a few issues. The feature changes here are updated because `compiler_builtins` no longer enables the `c` feature by default but we want to do so through our build still. Closes #60747 Closes #60782
2019-05-16strip synstructure consts from compiler docsAndy Russell-1/+1
2019-05-15Auto merge of #60832 - petrochenkov:CLazy, r=Mark-Simulacrumbors-0/+4
CMake: Do not print installation messages for up-to-date files Closes https://github.com/rust-lang/rust/issues/60830
2019-05-15Auto merge of #60775 - hellow554:no_bitrig, r=joshtriplettbors-1/+0
Remove bitrig support from rust Resolves #60743 using `find` and `rg` I delete every occurence of "bitrig" in the sources, expect for the llvm submodule (is this correct?). There's also this file https://github.com/rust-lang/rls/blob/5b8e99bb61958ca8abcb7c5eda70521726be1065/rls-analysis/test_data/rust-analysis/libstd-af9bacceee784405.json which contains a bitrig string in it. What to do with that?
2019-05-15rustbuild/LLVM: Do not print installation messages for up-to-date filesVadim Petrochenkov-0/+4
2019-05-14Rollup merge of #60719 - varkor:xpy-test-folder, r=Mark-SimulacrumMazdak Farrokhzad-2/+13
Allow subdirectories to be tested by x.py test Fixes https://github.com/rust-lang/rust/issues/60718. As far as I can tell, multiple `--test-args` flags are ignored (only the first is respected), so if you specify a subdirectory, you won't also be able to filter using `--test-args`. If you don't specify a subdirectory, `--test-args` will continue working as usual, so this is strictly an improvement on the current state of affairs.
2019-05-14Add commentvarkor-0/+6
2019-05-13Update src/bootstrap/util.rsPietro Albini-1/+1
Co-Authored-By: Jake Goulding <shepmaster@mac.com>
2019-05-13Remove bitrig support from rustMarcel Hellwig-1/+0
2019-05-13ci: remove fanout from the azure pipelines configPietro Albini-76/+6
2019-05-11Allow subdirectories to be tested by x.py testvarkor-2/+7
2019-05-10Make tests compatible with musl hostMateusz Mikuła-0/+4
2019-05-10Add Azure PipelinesJohn Erickson-8/+82
2019-05-09remove unneeded `extern crate`s from build toolsAndy Russell-21/+31
2019-05-05Update getopts to 0.2.19varkor-1/+1
2019-05-03Rollup merge of #60401 - JohnTitor:rename-log, r=davidtwcoMazdak Farrokhzad-1/+1
Rename `RUST_LOG` to `RUSTC_LOG` cc: #57985 I think we should also change these submodules: - rustc-guide - Cargo (rename to `CARGO_LOG`, cc: https://github.com/rust-lang/cargo/pull/6605, https://github.com/rust-lang/cargo/issues/6189) - miri - rls - rustfmt r? @davidtwco
2019-05-02Update getopts to 0.2.18varkor-1/+1
This is a proof-of-concept that the dependency unification fix works.
2019-05-02Prevent dependencies between std/test/rustc unifying with each othervarkor-4/+20
2019-05-02Auto merge of #60379 - froydnj:bootstrap-progress-fixes, r=kennytmbors-3/+9
intelligently handle older version of git in bootstrap If we fail to run with `--progress`, try running without instead. Fixes #57080.
2019-05-02Auto merge of #60156 - RalfJung:macos-rand, r=oli-obk,alexcrichtonbors-0/+1
use SecRandomCopyBytes on macOS in Miri This is a hack to fix https://github.com/rust-lang/miri/issues/686: on macOS, rustc will open `/dev/urandom` to initialize a `HashMap`. That's quite hard to emulate properly in Miri without a full-blown implementation of file descriptors. However, Miri needs an implementation of `SecRandomCopyBytes` anyway to support [getrandom](https://crates.io/crates/getrandom), so using it here should work just as well. This will only have an effect when libstd is compiled specifically for Miri, but that will generally be the case when people use `cargo miri`. This is clearly a hack, so I am opening this to start a discussion about whether we are okay with such a hack or not. Cc @oli-obk
2019-04-30Auto merge of #60262 - michaelwoerister:pgo-preinlining-pass, r=alexcrichtonbors-51/+22
PGO: Add a run-make test that makes sure that PGO profiling data is used by the compiler during optimizations. From the tests comment section: ``` # This test makes sure that PGO profiling data leads to cold functions being # marked as `cold` and hot functions with `inlinehint`. # The test program contains an `if` were actual execution only ever takes the # `else` branch. Accordingly, we expect the function that is never called to # be marked as cold. ``` r? @alexcrichton
2019-04-30Rename to RUSTC_LOGYuki OKUSHI-1/+1
2019-04-30Add local LLD to the PATH for run-make-fulldeps tests.Michael Woerister-0/+15
2019-04-29intelligently handle older version of git in bootstrapNathan Froyd-3/+9
If we fail to run with `--progress`, try running without instead. Fixes #57080.
2019-04-29bootstrap: Don't add LLVM's bin directory to the PATH for tool invocations.Michael Woerister-51/+0
2019-04-29compiletest: Make LLVM's bin directory available to run-make-fulldeps tests.Michael Woerister-0/+7
2019-04-27Rollup merge of #60315 - pietroalbini:fix-tools-version, r=Mark-SimulacrumMazdak Farrokhzad-2/+2
bootstrap: use correct version numbers for llvm-tools and lldb The current URLs for the `llvm-tools` and `lldb` components are a bit broken right now: ``` https://static.rust-lang.org/dist/2019-04-25/llvm-tools-1.34.1 (fc50f328b 2019-04-24)-aarch64-unknown-linux-gnu.tar.gz ``` This PR uses proper version numbers for those. Tested a dist build locally and everything works. r? @Mark-Simulacrum
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-10 15:26:29 +0000