The performance difference is negligible, but it makes me feel better.
Note that this does not remove some clones in `config`, because it would
require changing the logic around (and performance doesn't matter
for bootstrap).
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`
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
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`
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.
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.
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.
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
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.
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.
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.
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.
- 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
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
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.
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.
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`
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.
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.
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
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`).
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.
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.
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.
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.
