about summary refs log tree commit diff
path: root/src/bootstrap
AgeCommit message (Collapse)AuthorLines
2020-09-16Auto merge of #76781 - RalfJung:rollup-ve66o2j, r=RalfJungbors-28/+10
Rollup of 10 pull requests Successful merges: - #76056 (Add more info for Vec Drain doc) - #76062 (Vec slice example fix style and show type elision) - #76262 (Use inline(never) instead of cold) - #76335 (Make all methods of `Duration` unstably const) - #76366 (Add Arith Tests in Library) - #76369 (Move Various str tests in library) - #76534 (Add doc comments for From impls) - #76622 (Update bootstrap readme) - #76641 (Some cleanup changes and commenting) - #76662 (Fix liballoc test suite for Miri) Failed merges: r? `@ghost`
2020-09-16Rollup merge of #76622 - jyn514:bootstrap-readme, r=Mark-SimulacrumRalf Jung-28/+10
Update bootstrap readme - Reflect changes in x.py defaults - Remove recommendation to use nightly for incremental; it works fine on beta - Remove note that incremental chooses stage 1 by default; stage 1 is already the default - Update Discord -> Zulip r? @Mark-Simulacrum
2020-09-16Auto merge of #76625 - jyn514:default-stages, r=Mark-Simulacrumbors-42/+62
Make the default stage for x.py configurable This also allows configuring each sub-command individually. Possibly #76617 should land before this? I don't feel strongly either way, I don't mind waiting. Closes https://github.com/rust-lang/rust/issues/76165. r? `@Mark-Simulacrum`
2020-09-15Make the default stage for x.py configurableJoshua Nelson-42/+62
This allows configuring the default stage for each sub-command individually. - Normalize the stage as early as possible, so there's no confusion about which to use. - Don't add an explicit `stage` option in config.toml This offers no more flexibility than `*_stage` and makes it confusing which takes precedence. - Always give `--stage N` precedence over config.toml - Fix bootstrap tests This changes the tests to go through `Config::parse` so that they test the actual defaults, not the dummy ones provided by `default_opts`. To make this workable (and independent of the environment), it does not read `config.toml` for tests.
2020-09-15Enable shared linking to LLVM on non-WindowsMark Rousskov-0/+4
Windows doesn't quite support dynamic linking to LLVM yet, but on other platforms we do. In #76708, it was discovered that we dynamically link to LLVM from the LLVM tools (e.g., rust-lld), so we need the shared LLVM library to link against. That means that if we do not have a shared link to LLVM, and want LLVM tools to work, we'd be shipping two copies of LLVM on all of these platforms: one in librustc_driver and one in libLLVM. Also introduce an error into rustbuild if we do end up configured for shared linking on Windows.
2020-09-15Modify executable checking to be more universalMark Rousskov-0/+1
This uses a dummy file to check if the filesystem being used supports the executable bit in general.
2020-09-15Avoid printing dry run timingsMark Rousskov-1/+1
2020-09-14Fix generating rustc docs with non-default lib directory.Eric Huss-6/+14
2020-09-14Auto merge of #76549 - ehuss:lints-comments, r=wesleywiserbors-1/+64
Auto-generate lint documentation. This adds a tool which will generate the lint documentation in the rustc book automatically. This is motivated by keeping the documentation up-to-date, and consistently formatted. It also ensures the examples are correct and that they actually generate the expected lint. The lint groups table is also auto-generated. See https://github.com/rust-lang/compiler-team/issues/349 for the original proposal. An outline of how this works: - The `declare_lint!` macro now accepts a doc comment where the documentation is written. This is inspired by how clippy works. - A new tool `src/tools/lint-docs` scrapes the documentation and adds it to the rustc book during the build. - It runs each example and verifies its output and embeds the output in the book. - It does a few formatting checks. - It verifies that every lint is documented. - Groups are collected from `rustc -W help`. I updated the documentation for all the missing lints. I have also added an "Explanation" section to each lint providing a reason for the lint and suggestions on how to resolve it. This can lead towards a future enhancement of possibly showing these docs via the `--explain` flag to make them easily accessible and discoverable.
2020-09-13Link rustdoc lint docs to the rustdoc book.Eric Huss-3/+0
2020-09-13Auto-generate lint documentation.Eric Huss-1/+67
2020-09-13Fix CI LLVM to work on NixOS out of the boxAleksey Kladov-0/+2
2020-09-13Auto merge of #76588 - guswynn:debug_logging, r=jyn514,Mark-Simulacrumbors-0/+16
Add a dedicated debug-logging option to config.toml `@Mark-Simulacrum` and I were talking in zulip and we found that turning on debug/trace logging in rustc is fairly confusing, as it effectively depends on debug-assertions and is not documented as such. `@Mark-Simulacrum` mentioned that we should probably have a separate option for logging anyways. this diff adds that, having the option follow debug-assertions (so everyone's existing config.toml should be fine) and if the option is false to test I ran ./x.py test <something> twice, once with `debug-logging = false` and once with `debug-logging = true` and made sure i only saw trace's when it was true
2020-09-13Auto merge of #76349 - Mark-Simulacrum:dl-llvm, r=alexcrichtonbors-39/+172
Download LLVM from CI to bootstrap (linux-only to start) This follows #76332, adding support for using CI-built LLVM rather than building it locally. This should essentially "just work," but is left off by default in this PR. While we can support downloading LLVM for multiple host triples, this currently only downloads it for the build triple. That said, it should be possible to expand this relatively easily should multiple host triples be desired. Most people shouldn't be adjusting host/target triples though, so this should cover most use cases. Currently this downloads LLVM for the last bors-authored commit in the `git log`. This is a bit suboptimal -- we want the last bors-authored commit that touched the llvm-project submodule in basically all cases. But for now this just adds an extra ~20 MB download when rebasing atop latest master. Once we have a submodule bump landing after #76332, we can fix this behavior to reduce downloads further.
2020-09-12Set link-shared if LLVM ThinLTO is enabled in config.rsMark Rousskov-1/+8
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-12Download LLVM from CI to bootstrapMark Rousskov-38/+164
2020-09-12Auto merge of #76639 - Mark-Simulacrum:ci-hosts, r=pietroalbinibors-1/+1
Add host triples to CI builders This is a follow-up to #76415, which changed how x.py interprets cross-compilation target/host flags. This should fix the known cases, but I'm still working through CI logs before/after that PR to identify if anything else is missing.
2020-09-12Print all step timingsMark Rousskov-1/+1
It is really painful to inspect differences in what was built in CI if things are appearing and disappearing randomly as they hover around the 100ms mark. No matter what we choose there's always going to be quite a bit of variability on CI in timing, so we're going to see things appear and vanish.
2020-09-11Update bootstrap readmeJoshua Nelson-28/+10
- Reflect changes in x.py defaults - Remove recommendation to use nightly for incremental; it works fine on beta - Remove note that incremental chooses stage 1 by default; stage 1 is already the default - Update Discord -> Zulip
2020-09-11Auto merge of #76415 - Mark-Simulacrum:bootstrap-cross-compilation, ↵bors-86/+92
r=alexcrichton rustbuild: avoid trying to inversely cross-compile for build triple from host triples This changes rustbuild's cross compilation logic to better match what users expect, particularly, avoiding trying to inverse cross-compile for the build triple from host triples. That is, if build=A, host=B, target=B, we do not want to try and compile for A from B. Indeed, the only "known to run" triple when cross-compiling is the build triple A. When testing for a particular target we need to be able to run binaries compiled for that target though. The last commit also modifies the default set of host/target triples to avoid producing needless artifacts for the build triple: The new behavior is to respect --host and --target when passed as the *only* configured triples (no triples are implicitly added). The default for --host is the build triple, and the default for --target is the host triple(s), either configured or the default build triple. Fixes #76333 r? `@alexcrichton` if possible, otherwise we'll need to hunt down a reviewer
2020-09-11just max_level_infoGus Wynn-1/+1
2020-09-11Stop implicitly appending triples to config.toml hosts and targetsMark Rousskov-38/+46
Previously, the CLI --target/--host definitions and configured options differed in their effect: when setting these on the CLI, only the passed triples would be compiled for, while in config.toml we would also compile for the build triple and any host triples. This is needlessly confusing; users expect --target and --host to be identical to editing the configuration file. The new behavior is to respect --host and --target when passed as the *only* configured triples (no triples are implicitly added). The default for --host is the build triple, and the default for --target is the host triple(s), either configured or the default build triple.
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
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-08 14:08:19 +0000