about summary refs log tree commit diff
path: root/src/bootstrap
AgeCommit message (Collapse)AuthorLines
2020-09-11Verify we compile std without involving a b host compilerMark Rousskov-0/+10
2020-09-11Remove host parameter from step configurationsMark Rousskov-48/+36
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-11Auto merge of #76573 - Mark-Simulacrum:bootstrap-with-external-llvm, ↵bors-0/+9
r=alexcrichton Only copy LLVM into rust-dev with internal LLVM This avoids needing to figure out where to locate each of the components with an external LLVM. This component isn't manifested for rustup consumption and generally shouldn't matter for anyone except Rust's CI, so it is fine for it to not be complete elsewhere. Fixes #76572. r? `@alexcrichton`
2020-09-11Auto merge of #76381 - petrochenkov:nomingwcomp, r=Mark-Simulacrumbors-8/+0
rustbuild: Do not use `rust-mingw` component when bootstrapping windows-gnu targets Addresses https://github.com/rust-lang/rust/pull/76326#issuecomment-687273473 (ancient `x86_64-w64-mingw32-gcc` is selected as a linker wrapper, which is not usable in `use_lld=true` mode). Perhaps the comment about incompatible mingw was true in the past, but many things changed since then. With this change I was able to build everything successfully locally using a newer mingw toolchain, if it passes through the older toolchain on CI, then it should be good, I think.
2020-09-10add debug-logging to config.tomlGus Wynn-0/+16
2020-09-10Only copy LLVM into rust-dev with internal LLVMMark Rousskov-0/+9
This avoids needing to figure out where to locate each of the components with an external LLVM.
2020-09-10Auto merge of #76378 - petrochenkov:lldtest, r=Mark-Simulacrumbors-18/+38
rustbuild: Build tests with LLD if `use-lld = true` was passed Addresses https://github.com/rust-lang/rust/pull/76127#discussion_r479932392. Our test suite is generally ready to run with an explicitly specified linker (https://github.com/rust-lang/rust/pull/45191), so LLD specified with `use-lld = true` works as well. Only 4 tests fail (on `x86_64-pc-windows-msvc`): ``` ui/panic-runtime/lto-unwind.rs run-make-fulldeps/debug-assertions run-make-fulldeps/foreign-exceptions run-make-fulldeps/test-harness ``` All of them are legitimate issues with LLD (or at least with combination Rust+LLD) and manifest in segfaults on access to TLS (https://github.com/rust-lang/rust/pull/76127#issuecomment-683473325). UPD: These issues are caused by https://github.com/rust-lang/rust/issues/72145 and appear because I had `-Ctarget-cpu=native` set. UPD: Further commits build tests with LLD for non-MSVC targets and propagate LLD to more places when `use-lld` is enabled.
2020-09-09Rollup merge of #76472 - matthiaskrgr:llvm_cmake_vars, r=Mark-SimulacrumTyler Mandry-5/+0
rustbuild: don't set PYTHON_EXECUTABLE and WITH_POLLY cmake vars since they are no longer supported by llvm This resolves CMake Warning: Manually-specified variables were not used by the project: PYTHON_EXECUTABLE WITH_POLLY
2020-09-09Rollup merge of #74787 - petrochenkov:rustllvm, r=cuviperTyler Mandry-5/+5
Move `rustllvm` into `compiler/rustc_llvm` The `rustllvm` directory is not self-contained, it contains C++ code built by a build script of the `rustc_llvm` crate which is then linked into that crate. So it makes sense to make `rustllvm` a part of `rustc_llvm` and move it into its directory. I replaced `rustllvm` with more obvious `llvm-wrapper` as the subdirectory name, but something like `llvm-adapter` would work as well, other suggestions are welcome. To make things more confusing, the Rust side of FFI functions defined in `rustllvm` can be found in `rustc_codegen_llvm` rather than in `rustc_llvm`. Perhaps they need to be moved as well, but this PR doesn't do that. The presence of multiple LLVM-related directories in `src` (`llvm-project`, `rustllvm`, `librustc_llvm`, `librustc_codegen_llvm` and their predecessors) historically confused me and made me wonder about their purpose. With this PR we will have LLVM itself (`llvm-project`), a FFI crate (`rustc_llvm`, kind of `llvm-sys`) and a codegen backend crate using LLVM through the FFI crate (`rustc_codegen_llvm`).
2020-09-09Rollup merge of #76473 - ortem:fix-gcc-warning, r=jonas-schievinkTyler Mandry-2/+2
Add missed spaces to GCC-WARNING.txt
2020-09-09Move `rustllvm` into `rustc_llvm`Vadim Petrochenkov-5/+5
2020-09-09Rollup merge of #76379 - petrochenkov:nodegen, r=Mark-SimulacrumDylan DPC-9/+5
rustbuild: Remove `Mode::Codegen` It's no longer used.
2020-09-08Auto merge of #76332 - Mark-Simulacrum:bootstrap-llvm, r=pietroalbinibors-0/+83
Add rust-dev component to support rustc development This is preparatory work for permitting rustc developers to use CI-built LLVM rather than building it locally. Unlike distro-built LLVM, CI built LLVM is essentially guaranteed to behave perfectly for local development -- it is fully up to date, and carries all necessary patches. This is a separate PR from #76349 because it needs to land before that one, since we want a master build with the full CI LLVM to be available for easier testing.
2020-09-08rustbuild: don't set PYTHON_EXECUTABLE and WITH_POLLY cmake vars since they ↵Matthias Krüger-5/+0
are no longer supported by llvm CMake Warning: Manually-specified variables were not used by the project: PYTHON_EXECUTABLE WITH_POLLY
2020-09-08Add missed spaces to GCC-WARNING.txtortem-2/+2
2020-09-07Dedicated rust development tarballMark Rousskov-0/+83
This currently includes libLLVM, llvm-config, and FileCheck, but will perhaps expand to more tooling overtime. It should be considered entirely unstable and may change at any time.
2020-09-06Make bootstrap build on stableMark Rousskov-5/+4
This is generally a good idea, and will help with being able to build bootstrap without Python over time as it means we can "just" build with cargo +beta build rather than needing the user to set environment variables. This is a minor step, but a necessary one on that road.
2020-09-07rustbuild: Deduplicate LLD checks slightlyVadim Petrochenkov-10/+13
2020-09-07rustbuild: Propagate LLD to more places when `use-lld` is enabledVadim Petrochenkov-3/+18
2020-09-07rustbuild: Build tests with LLD if `use-lld = true` was passed (non-msvc)Vadim Petrochenkov-0/+6
2020-09-07rustbuild: Build tests with LLD if `use-lld = true` was passedVadim Petrochenkov-13/+9
2020-09-06Auto merge of #76326 - mati865:use_lld-no-linker, r=Mark-Simulacrumbors-1/+6
Fix rust.use-lld when linker is not set Fixes https://github.com/rust-lang/rust/pull/76127#issuecomment-685419195 Previously when `[<target>].linker` was not configured `rust.use-lld` would set it to `rust-lld` on platforms where it should not.
2020-09-05rustbuild: Do not use `rust-mingw` component when bootstrapping windows-gnu ↵Vadim Petrochenkov-8/+0
targets
2020-09-05rustbuild: Remove `Mode::Codegen`Vadim Petrochenkov-9/+5
2020-09-04There isn't a way to pass --remove yet, but you can rm if u likeCassandra Fridkin-1/+26
2020-09-04Fix rust.use-lld when linker is not setMateusz Mikuła-1/+6
2020-09-03Check test/example/benchmark on x.py checkMark Rousskov-2/+61
Often when modifying compiler code you'll miss that you've changed an API used by unit tests, since x.py check didn't previously catch that. It's also useful to have this for editing with rust-analyzer and similar tooling where editing tests previously didn't notify you of errors in test files.
2020-09-02Avoid spurious print outs during dryrunMark Rousskov-2/+2
2020-09-01Move ninja requirements to a dynamic check, when actually buildingMark Rousskov-45/+51
It isn't practical to determine whether we'll build LLVM very early in the pipeline, so move the ninja checking to a dynamic check.
2020-08-31Rollup merge of #76127 - petrochenkov:lld, r=Mark-SimulacrumAleksey Kladov-6/+2
rustbuild: Remove one LLD workaround The version of LLD shipped with Rust no longer have this issue. Closes https://github.com/rust-lang/rust/issues/68647
2020-08-31rustbuild: Remove one LLD workaroundVadim Petrochenkov-6/+2
2020-08-30cleanup: Remove duplicate library names from `Cargo.toml`sVadim Petrochenkov-2/+1
2020-08-30mv compiler to compiler/mark-7/+8
2020-08-30Rollup merge of #76015 - ortem:fix-lldb-script, r=Mark-SimulacrumDylan DPC-0/+1
Fix loading pretty-printers in rust-lldb script Pretty-printers loading in `rust-lldb` script was broken in https://github.com/rust-lang/rust/pull/72357 This fixes https://github.com/rust-lang/rust/issues/76006
2020-08-30Rollup merge of #75975 - matklad:snapshot-tests, r=Mark-SimulacrumDylan DPC-5/+5
Allow --bess ing expect-tests in tools I haven't tried this, but I think this should do the trick, as `RustdocCrate` is a special step in bootstrap, which uses `tool_caro` r? @ghost
2020-08-29Auto merge of #75713 - mati865:netbsd_zlib, r=Mark-Simulacrumbors-3/+1
Enable zlib for NetBSD NetBSD Docker dist job passed locally.
2020-08-29Allow --bess ing expect-tests in toolsAleksey Kladov-5/+5
See #75773 and #75775
2020-08-29Auto merge of #74922 - joshtriplett:ninja-by-default, r=Mark-Simulacrumbors-2/+12
Set ninja=true by default Ninja substantially improves LLVM build time. On a 96-way system, using Make took 248s, and using Ninja took 161s, a 35% improvement. We already require a variety of tools to build Rust. If someone wants to build without Ninja (for instance, to minimize the set of packages required to bootstrap a new target), they can easily set `ninja=false` in `config.toml`. Our defaults should help people build Rust (and LLVM) faster, to speed up development.
2020-08-28Disable ninja on the dry-run builderJosh Triplett-0/+1
2020-08-28Fix loading pretty-printers in rust-lldb scriptortem-0/+1
2020-08-27Auto merge of #75947 - pietroalbini:bootstrap-update, r=Mark-Simulacrumbors-1/+1
Bump version to 1.48 and update cfg(bootstrap)s r? @Mark-Simulacrum
2020-08-27Rollup merge of #75758 - bpangWR:master, r=Mark-SimulacrumDylan DPC-1/+6
Fixes for VxWorks r? @alexcrichton
2020-08-26Provide a better diagnostic if ninja isn't installedJosh Triplett-2/+10
Let people know that they can set ninja=false if they don't want to install ninja.
2020-08-26Set ninja=true by defaultJosh Triplett-0/+1
Ninja substantially improves LLVM build time. On a 96-way system, using Make took 248s, and using Ninja took 161s, a 35% improvement. We already require a variety of tools to build Rust. If someone wants to build without Ninja (for instance, to minimize the set of packages required to bootstrap a new target), they can easily set `ninja=false` in `config.toml`. Our defaults should help people build Rust (and LLVM) faster, to speed up development.
2020-08-26bump version to 1.48Pietro Albini-1/+1
2020-08-25For VxWorks:Pang, Baoshan-1/+6
fix building errors use wr-c++ as linker
2020-08-25Auto merge of #75773 - matklad:snapshot-tests, r=Mark-Simulacrumbors-0/+5
Introduce expect snapshot testing library into rustc Snapshot testing is a technique for writing maintainable unit tests. Unlike usual `assert_eq!` tests, snapshot tests allow to *automatically* upgrade expected values on test failure. In a sense, snapshot tests are inline-version of our beloved UI-tests. Example: ![expect](https://user-images.githubusercontent.com/1711539/90888810-3bcc8180-e3b7-11ea-9626-d06e89e1a0bb.gif) A particular library we use, `expect_test` provides an `expect!` macro, which creates a sort of self-updating string literal (by using `file!` macro). Self-update is triggered by setting `UPDATE_EXPECT` environmental variable (this info is printed during the test failure). This library was extracted from rust-analyzer, where we use it for most of our tests. There are some other, more popular snapshot testing libraries: * https://github.com/mitsuhiko/insta * https://github.com/aaronabramov/k9 The main differences of `expect` are: * first-class snapshot objects (so, tests can be written as functions, rather than as macros) * focus on inline-snapshots (but file snapshots are also supported) * restricted feature set (only `assert_eq` and `assert_debug_eq`) * no extra runtime (ie, no `cargo insta`) See rust-analyzer/rust-analyzer#5101 for a an extended comparison. It is unclear if this testing style will stick with rustc in the long run. At the moment, rustc is mainly tested via integrated UI tests. But in the library-ified world, unit-tests will become somewhat more important (that's why use use `rustc_lexer` library-ified library as an example in this PR). Given that the cost of removal shouldn't be too high, it probably makes sense to just see if this flies!
2020-08-25Enable zlib for NetBSDMateusz Mikuła-3/+1
2020-08-24Auto merge of #75625 - mati865:mingw-cross-compile, r=Mark-Simulacrumbors-1/+1
Fix windows-gnu host cross-compilation Fixes https://github.com/rust-lang/rust/issues/64218 Also turns out it's faster to run Linux virtual machine on Windows and cross-compile `./x.py dist` than doing it on Windows directly...
2020-08-24Introduce expect snapshot testing library into rustcAleksey Kladov-0/+5
Snapshot testing is a technique for writing maintainable unit tests. Unlike usual `assert_eq!` tests, snapshot tests allow to *automatically* upgrade expected values on test failure. In a sense, snapshot tests are inline-version of our beloved UI-tests. Example: ![expect](https://user-images.githubusercontent.com/1711539/90888810-3bcc8180-e3b7-11ea-9626-d06e89e1a0bb.gif) A particular library we use, `expect_test` provides an `expect!` macro, which creates a sort of self-updating string literal (by using `file!` macro). Self-update is triggered by setting `UPDATE_EXPECT` environmental variable (this info is printed during the test failure). This library was extracted from rust-analyzer, where we use it for most of our tests. There are some other, more popular snapshot testing libraries: * https://github.com/mitsuhiko/insta * https://github.com/aaronabramov/k9 The main differences of `expect` are: * first-class snapshot objects (so, tests can be written as functions, rather than as macros) * focus on inline-snapshots (but file snapshots are also supported) * restricted feature set (only `assert_eq` and `assert_debug_eq`) * no extra runtime (ie, no `cargo insta`) See https://github.com/rust-analyzer/rust-analyzer/pull/5101 for a an extended comparison. It is unclear if this testing style will stick with rustc in the long run. At the moment, rustc is mainly tested via integrated UI tests. But in the library-ified world, unit-tests will become somewhat more important (that's why use use `rustc_lexer` library-ified library as an example in this PR). Given that the cost of removal shouldn't be too high, it probably makes sense to just see if this flies!
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-03-01 02:00:24 +0000