| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
bootstrap completely ignores all errors when detecting a rustup version,
so this wasn't noticed before.
Fixes the following error:
```
rustup not detected: a bytes-like object is required, not 'str'
falling back to auto-detect
```
This also takes the opportunity to only call rustup and other external
commands only once during startup.
|
|
|
|
Move rustdoc/rustdoc-json to rustdoc-json
Scaffold rustdoc-json test mode
Implement run_rustdoc_json_test
Fix up python
Make tidy happy
|
|
Move intra-doc link tests into a subdirectory
They were starting to get unwieldy.
r? ``@Manishearth``
|
|
Add -Z normalize-docs and enable it for compiler docs
Works around https://github.com/rust-lang/rust/issues/79459 by only enabling normalization for the compiler itself (and anyone who opts-in on nightly). Eventually I want to remove this and enable normalization by default, but that's turned out to be [really hard](https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/How.20do.20I.20normalize.20projection.20types.20to.20a.20single.20type.3F/near/218125195).
This uses a command line option instead of a feature gate so it's easier to pass it to all crates at once. Theoretically it's better to use a feature gate instead so that it's easier for people to use on docs.rs, but I'm also not terribly concerned with how easy it to use a temporary hack.
Addresses https://github.com/rust-lang/rust/issues/77459.
|
|
Validate lint docs separately.
This addresses some concerns raised in https://github.com/rust-lang/rust/pull/76549#issuecomment-727638552 about errors with the lint docs being confusing and cumbersome. Errors from validating the lint documentation were being generated during `x.py doc` (and `x.py dist`), since extraction and validation are being done in a single step. This changes it so that extraction and validation are separated, so that `x.py doc` will not error if there is a validation problem, and tests are moved to `x.py test src/tools/lint-docs`.
This includes the following changes:
* Separate validation to `x.py test`.
* Added some more documentation on how to more easily modify and test the docs.
* Added more help to the error messages to hopefully provide more information on how to fix things.
The first commit just moves the code around, so you may consider looking at the other commits for a smaller diff.
|
|
|
|
This also changes the builder to allow using
`x.py test src/test/rustdoc-ui/intra-doc`; before, it would panic that
no paths were found.
|
|
|
|
|
|
|
|
x.py: allow a custom string appended to the version
This adds `rust.description` to the config as a descriptive string to be
appended to `rustc --version` output, which is also used in places like
debuginfo `DW_AT_producer`. This may be useful for supplementary build
information, like distro-specific package versions.
For example, in Fedora 33, `gcc --version` outputs:
gcc (GCC) 10.2.1 20201016 (Red Hat 10.2.1-6)
With this change, we can add similar vendor info to `rustc --version`.
|
|
Make compiletest testing use the local sysroot
We already set `compiletest` to use the local sysroot in #68019, but
that missed the configuration for testing `compiletest` itself.
|
|
Allow using `download-ci-llvm` from directories other than the root
Previously, bootstrap.py would attempt to find the LLVM commit from
`src/llvm-project`. However, it assumed it was always being run from the
top-level directory, which isn't always the case.
Before:
```
downloading https://ci-artifacts.rust-lang.org/rustc-builds//rust-dev-nightly-x86_64-unknown-linux-gnu.tar.gz
curl: (22) The requested URL returned error: 404
failed to run: curl -# -y 30 -Y 10 --connect-timeout 30 --retry 3 -Sf -o /tmp/tmppyh4w8 https://ci-artifacts.rust-lang.org/rustc-builds//rust-dev-nightly-x86_64-unknown-linux-gnu.tar.gz
Build completed unsuccessfully in 0:00:02
```
After:
```
downloading https://ci-artifacts.rust-lang.org/rustc-builds/430feb24a46993e5073c1bb1b39da190d83fa2bf/rust-dev-nightly-x86_64-unknown-linux-gnu.tar.gz
###################################################################################################################################################################### 100.0%
extracting /home/joshua/rustc/src/bootstrap/build/cache/llvm-430feb24a46993e5073c1bb1b39da190d83fa2bf-False/rust-dev-nightly-x86_64-unknown-linux-gnu.tar.gz
```
r? ```@Mark-Simulacrum```
cc ```@pnkfelix```
|
|
fix handling the default config for profiler and sanitizers
#78354 don't handle the case that user don't add any target-specific config in `[target.*]` of `config.toml`:
```toml
changelog-seen = 2
[llvm]
link-shared = true
[build]
sanitizers = true
profiler = true
[install]
[rust]
[dist]
```
The previes code handle the default config in `Config::prase()`:
```rust
target.sanitizers = cfg.sanitizers.unwrap_or(build.sanitizers.unwrap_or_default());
target.profiler = cfg.profiler.unwrap_or(build.profiler.unwrap_or_default());
config.target_config.insert(TargetSelection::from_user(&triple), target);
```
In this case, `toml.target` don't contain any target, so the above code won't execute. Instead, a default `Target` is insert in https://github.com/rust-lang/rust/blob/c919f490bbcd2b29b74016101f7ec71aaa24bdbb/src/bootstrap/sanity.rs#L162-L166
The default value for `bool` is false, hence the issue in #79124
This fix change the type of `sanitizers` and `profiler` to `Option<bool>`, so the default value is `None`, and fallback config is handled in `Config::sanitizers_enabled` and `Config::profiler_enabled`
fix #79124
cc `@Mark-Simulacrum` `@richkadel`
|
|
We already set `compiletest` to use the local sysroot in #68019, but
that missed the configuration for testing `compiletest` itself.
|
|
Previously, bootstrap.py would attempt to find the LLVM commit from
`src/llvm-project`. However, it assumed it was always being run from the
top-level directory, which isn't always the case.
Before:
```
downloading https://ci-artifacts.rust-lang.org/rustc-builds//rust-dev-nightly-x86_64-unknown-linux-gnu.tar.gz
curl: (22) The requested URL returned error: 404
failed to run: curl -# -y 30 -Y 10 --connect-timeout 30 --retry 3 -Sf -o /tmp/tmppyh4w8 https://ci-artifacts.rust-lang.org/rustc-builds//rust-dev-nightly-x86_64-unknown-linux-gnu.tar.gz
Build completed unsuccessfully in 0:00:02
```
After:
```
downloading https://ci-artifacts.rust-lang.org/rustc-builds/430feb24a46993e5073c1bb1b39da190d83fa2bf/rust-dev-nightly-x86_64-unknown-linux-gnu.tar.gz
###################################################################################################################################################################### 100.0%
extracting /home/joshua/rustc/src/bootstrap/build/cache/llvm-430feb24a46993e5073c1bb1b39da190d83fa2bf-False/rust-dev-nightly-x86_64-unknown-linux-gnu.tar.gz
```
|
|
|
|
Historically the stable tarballs were named after the version number of
the specific tool, instead of the version number of Rust. For example,
both of the following tarballs were part of the same release:
rustc-1.48.0-x86_64-unknown-linux-gnu.tar.xz
cargo-0.49.0-x86_64-unknown-linux-gnu.tar.xz
PR #77336 changed the dist code to instead use Rust's version number for
all the tarballs, regardless of the tool they contain:
rustc-1.48.0-x86_64-unknown-linux-gnu.tar.xz
cargo-1.48.0-x86_64-unknown-linux-gnu.tar.xz
Because of that there is no need anymore to have a separate `cargo`
field in src/stage0.txt, as the Cargo version will always be the same as
the rustc version. This PR removes the field, simplifying the code and
the maintenance work required while producing releases.
|
|
This adds `rust.description` to the config as a descriptive string to be
appended to `rustc --version` output, which is also used in places like
debuginfo `DW_AT_producer`. This may be useful for supplementary build
information, like distro-specific package versions.
For example, in Fedora 33, `gcc --version` outputs:
gcc (GCC) 10.2.1 20201016 (Red Hat 10.2.1-6)
With this change, we can add similar vendor info to `rustc --version`.
|
|
Install CI llvm into the library directory
In other words, my concern in https://github.com/rust-lang/rust/issues/78932#issuecomment-725781767 was perfectly justified by something we were already doing. For now just special case CI LLVM, but in the future we may want a more general fix.
Fixes #79071.
r? `@alexcrichton`
|
|
|
|
Print 'checking cranelift artifacts' to easily separate it from other artifacts
Before:
```
Checking rustdoc artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
Checking rustdoc v0.0.0 (/home/joshua/rustc/src/librustdoc)
Checking rustdoc-tool v0.0.0 (/home/joshua/rustc/src/tools/rustdoc)
Finished release [optimized] target(s) in 2.08s
Checking regalloc v0.0.31
Checking gimli v0.22.0
Checking object v0.21.1
Checking cranelift-codegen v0.67.0 (https://github.com/bytecodealliance/wasmtime/?branch=main#44cbdece)
Checking cranelift-module v0.67.0 (https://github.com/bytecodealliance/wasmtime/?branch=main#44cbdece)
Checking cranelift-native v0.67.0 (https://github.com/bytecodealliance/wasmtime/?branch=main#44cbdece)
Checking cranelift-frontend v0.67.0 (https://github.com/bytecodealliance/wasmtime/?branch=main#44cbdece)
Checking cranelift-object v0.67.0 (https://github.com/bytecodealliance/wasmtime/?branch=main#44cbdece)
Checking cranelift-simplejit v0.67.0 (https://github.com/bytecodealliance/wasmtime/?branch=main#44cbdece)
Checking rustc_codegen_cranelift v0.1.0 (/home/joshua/rustc/compiler/rustc_codegen_cranelift)
Finished release [optimized] target(s) in 10.55s
```
After:
```
Checking rustdoc artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
Checking rustdoc v0.0.0 (/home/joshua/rustc/src/librustdoc)
Checking rustdoc-tool v0.0.0 (/home/joshua/rustc/src/tools/rustdoc)
Finished release [optimized] target(s) in 2.08s
Checking cranelift artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
Checking cranelift-codegen v0.67.0 (https://github.com/bytecodealliance/wasmtime/?branch=main#44cbdece)
```
r? `@bjorn3`
`@bors` delegate=bjorn3
|
|
Add `--color` support to bootstrap
When running under external utilities which wrap x.py, it can be convenient to force color support on.
|
|
Avoid installing external LLVM dylibs
If the LLVM was externally provided, then we don't currently copy artifacts into
the sysroot. This is not necessarily the right choice (in particular, it will
require the LLVM dylib to be in the linker's load path at runtime), but the
common use case for external LLVMs is distribution provided LLVMs, and in that
case they're usually in the standard search path (e.g., /usr/lib) and copying
them here is going to cause problems as we may end up with the wrong files and
isn't what distributions want.
This behavior may be revisited in the future though.
Fixes #78932.
|
|
Include llvm-as in llvm-tools-preview component
Including `llvm-as` adds the ability to include assembly language fragments that can be inlined using LTO while making sure the correct version of LLVM is always used.
|
|
Before:
```
Checking rustdoc artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
Checking rustdoc v0.0.0 (/home/joshua/rustc/src/librustdoc)
Checking rustdoc-tool v0.0.0 (/home/joshua/rustc/src/tools/rustdoc)
Finished release [optimized] target(s) in 2.08s
Checking regalloc v0.0.31
Checking gimli v0.22.0
Checking object v0.21.1
Checking cranelift-codegen v0.67.0 (https://github.com/bytecodealliance/wasmtime/?branch=main#44cbdece)
Checking cranelift-module v0.67.0 (https://github.com/bytecodealliance/wasmtime/?branch=main#44cbdece)
Checking cranelift-native v0.67.0 (https://github.com/bytecodealliance/wasmtime/?branch=main#44cbdece)
Checking cranelift-frontend v0.67.0 (https://github.com/bytecodealliance/wasmtime/?branch=main#44cbdece)
Checking cranelift-object v0.67.0 (https://github.com/bytecodealliance/wasmtime/?branch=main#44cbdece)
Checking cranelift-simplejit v0.67.0 (https://github.com/bytecodealliance/wasmtime/?branch=main#44cbdece)
Checking rustc_codegen_cranelift v0.1.0 (/home/joshua/rustc/compiler/rustc_codegen_cranelift)
Finished release [optimized] target(s) in 10.55s
```
After:
```
Checking rustdoc artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
Checking rustdoc v0.0.0 (/home/joshua/rustc/src/librustdoc)
Checking rustdoc-tool v0.0.0 (/home/joshua/rustc/src/tools/rustdoc)
Finished release [optimized] target(s) in 2.08s
Checking cranelift artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
Checking cranelift-codegen v0.67.0 (https://github.com/bytecodealliance/wasmtime/?branch=main#44cbdece)
```
|
|
This allows using bootstrap with https://github.com/Canop/bacon.
|
|
If the LLVM was externally provided, then we don't currently copy artifacts into
the sysroot. This is not necessarily the right choice (in particular, it will
require the LLVM dylib to be in the linker's load path at runtime), but the
common use case for external LLVMs is distribution provided LLVMs, and in that
case they're usually in the standard search path (e.g., /usr/lib) and copying
them here is going to cause problems as we may end up with the wrong files and
isn't what distributions want.
This behavior may be revisited in the future though.
|
|
|
|
|
|
Including llvm-as adds the ability to include assembly language fragments
that can be inlined using LTO.
|
|
Ship llvm-cov through llvm-tools
`llvm-cov` is used to generate coverage report with LLVM InstrProf-based code coverage #34701.
So if `llvm-cov` is shipped through llvm-tools, users can try it easily accorging to the instruction of [The Rust Unstable Book](https://doc.rust-lang.org/nightly/unstable-book/compiler-flags/source-based-code-coverage.html).
|
|
Support enable/disable sanitizers/profiler per target
This PR add options under `[target.*]` of `config.toml` which can enable or disable sanitizers/profiler runtime for corresponding target.
If these options are empty, the global options under `[build]` will take effect.
Fix #78329
|
|
Vendor libtest's dependencies in the rust-src component
This is the Rust side of https://github.com/rust-lang/wg-cargo-std-aware/issues/23
Note that this won't produce a useful result for `cargo -Zbuild-std` if there are multiple versions of a crate vendored, but will otherwise produce a valid vendor dir.
See https://github.com/rust-lang/cargo/pull/8834 for the other half of this change.
|
|
|
|
Enable LLVM Polly via llvm-args.
I think doing it this way is better than in #51061. Polly has other useful options and we probably don't want to create a `-Z` flag for each one of them.
[Benchmark](https://gist.github.com/JRF63/9a6268b91720958e90dbe7abffe20298)
I noticed that `-lto` seems to interfere with polly in this specific microbenchmark, as enabling it causes the perf to drop to that of non-polly builds.
Other related PRs: #75615
|
|
Infer the default host target from the host toolchain if possible
- `beta-x86_64-unknown-linux-gnu` has beta stripped
- `rustc2` is ignored
This fixes ongoing issues where x.py will detect the wrong host triple
between MSVC and GNU.
I don't think this will break anyone's workflow - I'd be very surprised if you a) had no `[build]` section in `config.toml`, b) had rustc installed, and c) expected the default target to be something other than the default target used by `rustc`. But I could be wrong - I'm happy to hear user stories :)
Fixes https://github.com/rust-lang/rust/issues/78150.
r? ``@Mark-Simulacrum``
cc ``@Lokathor``
|
|
This is the Rust side of https://github.com/rust-lang/wg-cargo-std-aware/issues/23
|
|
Compile rustc crates with the initial-exec TLS model
This should produce more efficient code, with fewer calls to
__tls_get_addr. The tradeoff is that libraries using it won't work with
dlopen, but that shouldn't be a problem for rustc's internal libraries.
|
|
Honor the rustfmt setting in config.toml
Prior to this, setting the rustfmt configuration was ignored:
```
% mkdir example
% cd example
% ../configure --set build.rustfmt=/usr/bin/true
% ../x.py fmt
./x.py fmt is not supported on this channel
failed to run: /Users/shep/Projects/rust/example/build/bootstrap/debug/bootstrap fmt
Build completed unsuccessfully in 0:00:01
```
And after:
```
% ../x.py fmt
Build completed successfully in 0:00:11
```
r? `@Mark-Simulacrum`
|
|
Fix run-make tests running when LLVM is disabled
The `--cc`, `--cxx`, `--cflags` and `--ar` flags were only passed to compiletest when `builder.config.llvm_enabled()` returned true. This is preventing me from running the tests on cg_clif.
|
|
Prior to this, setting the rustfmt configuration was ignored:
```
% mkdir example
% cd example
% ../configure --set build.rustfmt=/usr/bin/true
% ../x.py fmt
./x.py fmt is not supported on this channel
failed to run: /Users/shep/Projects/rust/example/build/bootstrap/debug/bootstrap fmt
Build completed unsuccessfully in 0:00:01
```
And after:
```
% ../x.py fmt
Build completed successfully in 0:00:11
```
|
