| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
bootstrap: Configurable musl libdir
Make it possible to customize the location of musl libdir using
musl-libdir in config.toml, e.g., to use lib64 instead of lib.
|
|
|
|
r=Mark-Simulacrum
rustbuild: Move compiler-builtins build logic to manifest
This commit moves the compiler-builtins-specific build logic from
`src/bootstrap/bin/rustc.rs` into the workspace `Cargo.toml`'s
`[profile]` configuration. Now that rust-lang/cargo#7253 is fixed we can
ensure that Cargo knows about debug assertions settings, and it can also
be configured to specifically disable debug assertions unconditionally
for compiler-builtins. This should improve rebuild logic when
debug-assertions settings change and also improve build-std integration
where Cargo externally now has an avenue to learn how to build
compiler-builtins as well.
|
|
This commit moves the compiler-builtins-specific build logic from
`src/bootstrap/bin/rustc.rs` into the workspace `Cargo.toml`'s
`[profile]` configuration. Now that rust-lang/cargo#7253 is fixed we can
ensure that Cargo knows about debug assertions settings, and it can also
be configured to specifically disable debug assertions unconditionally
for compiler-builtins. This should improve rebuild logic when
debug-assertions settings change and also improve build-std integration
where Cargo externally now has an avenue to learn how to build
compiler-builtins as well.
|
|
Update mdbook
This updates mdbook to 0.4. The list of changes can be found at https://github.com/rust-lang/mdBook/blob/master/CHANGELOG.md#mdbook-040. I think the most important one is the change to include fonts with the book instead of using the Google Fonts CDN. This adds a few megabytes of fonts to the docs component. It may be possible to share the fonts across the books, but would take a fair bit of work to make that happen, so I'm not sure if it is necessary.
This also removes mdbook-linkcheck. It is currently not being used, and I don't foresee it going back into use anytime soon. I would prefer not to maintain something that isn't being used, and it removes a very large number of dependencies.
|
|
Bootstrap: detect Windows based on sys.platform
Closes #73689.
|
|
Fortanix SGX target libunwind build process changes
Ticket: https://github.com/fortanix/rust-sgx/issues/174
LLVM related changes (merged): https://github.com/rust-lang/llvm-project/pull/57
Description: libunwind changes needed to run code in sgx environment via rust-sgx.
Target that uses this in rust: x86_64-fortanix-unknown-sgx.
Without this change, rust std for this toolchain is forced to use a precompiled library loaded via environment variable.
With this change we act the same as musl target.
|
|
|
|
|
|
|
|
|
|
|
|
r=Mark-Simulacrum
bootstrap: no `config.toml` exists regression
Fixes #73574.
This PR fixes a regression introduced in #73317 where an oversight meant that `config.toml` was assumed to exist.
|
|
|
|
This commit fixes a regression introduced in #73317 where an oversight
meant that `config.toml` was assumed to exist.
Signed-off-by: David Wood <david@davidtw.co>
|
|
Enable LLVM zlib
Compilers may generate ELF objects with compressed sections (although rustc currently doesn't do this). Currently, when linking these with `rust-lld`, you'll get this error:
`rust-lld: error: ...: contains a compressed section, but zlib is not available`
This enables zlib when building LLVM.
|
|
Update CFGuard syntax
Update the naming and syntax of the control-flow-guard option, as discussed in #68793.
r? @Mark-Simulacrum
|
|
RISC-V Emulated Testing
Adds a disabled docker image on which to run RISC-V tests. Based on the armhf image.
Test using
```
./src/ci/docker/run.sh riscv64gc-linux
```
cc: @msizanoen1
|
|
|
|
|
|
Add src/librustdoc as an alias for src/tools/rustdoc
No one actually works with src/tools/rustdoc, it's almost empty.
Closes https://github.com/rust-lang/rust/issues/73439
|
|
Speed up bootstrap a little.
The bootstrap script was calling `cargo metadata` 3 times (or 6 with `-v`). This is a very expensive operation, and this attempts to avoid the extra calls. On my system, a simple command like `./x.py test -h -v` goes from about 3 seconds to 0.4.
An overview of the changes:
- Call `cargo metadata` only once with `--no-deps`. Optional dependencies are filtered in `in_tree_crates` (handling `profiler_builtins` and `rustc_codegen_llvm` which are driven by the config).
- Remove a duplicate call to `metadata::build` when using `-v`. I'm not sure why it was there, it looks like a mistake or vestigial from previous behavior.
- Remove check for `_shim`, I believe all the `_shim` crates are now gone.
- Remove check for `rustc_` and `*san` for `test::Crate::should_run`, these are no longer dependencies in the `test` tree.
- Use relative paths in `./x.py test -h -v` output.
- Some code cleanup (remove unnecessary `find_compiler_crates`, etc.).
- Show suite paths (`src/test/ui/...`) in `./x.py test -h -v` output.
- Some doc comments.
|
|
r=Mark-Simulacrum
bootstrap/install.rs: support a nonexistent `prefix` in `x.py install`
PR #49778 introduced fs::canonicalize() which fails for a nonexistent path.
This is a surprise for someone used to GNU Autotools' configure which can create any necessary intermediate directories in prefix.
This change makes it run fs::create_dir_all() before canonicalize().
|
|
bootstrap: read config from $RUST_BOOTSTRAP_CONFIG
This PR modifies bootstrap so that `config.toml` is read first from `RUST_BOOTSTRAP_CONFIG`, then `--config` and finally `config.toml` in the current directory.
This is a subjective change, intended to improve the ergnomics when using "development shells" for rustc development (for example, using tools such as Nix) which set environment variables to ensure a reproducible environment (these development shells can then be version controlled, e.g. [my rustc shell](https://github.com/davidtwco/veritas/blob/6b74a5c170b6efb2c7b094352932f9158f97eec0/nix/shells/rustc.nix)). By optionally reading `config.toml` from an environment variable, a `config.toml` can be defined in the development shell and a path to it exposed in the `RUST_BOOTSTRAP_CONFIG` environment variable - avoiding the need to manually symlink the contents of this file to `config.toml` in the working directory.
|
|
Create self-contained directory and move there some of external binaries/libs
One of the steps to reach design described in https://github.com/rust-lang/rust/issues/68887#issuecomment-633048380
This PR moves things around and allows link code to handle the new directory structure.
|
|
Make it possible to customize the location of musl libdir using
musl-libdir in config.toml, e.g., to use lib64 instead of lib.
|
|
No one actually works with src/tools/librustdoc, it's almost empty.
|
|
r=hanna-kruppe,Mark-Simulacrum
[RISC-V] Do not force frame pointers
We have been seeing some very inefficient code that went away when using
`-Cforce-frame-pointers=no`. For instance `core::ptr::drop_in_place` at
`-Oz` was compiled into a function which consisted entirely of saving
registers to the stack, then using the frame pointer to restore the same
registers (without any instructions between the prolog and epilog).
The RISC-V LLVM backend supports frame pointer elimination, so it makes
sense to allow this to happen when using Rust. It's not clear to me that
frame pointers have ever been required in the general case.
In rust-lang/rust#61675 it was pointed out that this made reassembling
stack traces easier, which is true, but there is a code generation
option for forcing frame pointers, and I feel the default should not be
to require frame pointers, given it demonstrably makes code size worse
(around 10% in some embedded applications).
The kinds of targets mentioned in rust-lang/rust#61675 are popular, but
should not dictate that code generation should be worse for all RISC-V
targets, especially as there is a way to use CFI information to
reconstruct the stack when the frame pointer is eliminated. It is also
a misconception that `fp` is always used for the frame pointer. `fp` is
an ABI name for `x8` (aka `s0`), and if no frame pointer is required,
`x8` may be used for other callee-saved values.
---
I am partly posting this to get feedback from @fintelia who introduced the change to require frame pointers, and @hanna-kruppe who had issues with the original PR. I would understand if we wanted to remove this setting on only a subset of RISC-V targets, but my preference would be to remove this setting everywhere.
There are more details on the code size savings seen in Tock here: https://github.com/tock/tock/pull/1660
|
|
|
|
Rollup of 8 pull requests
Successful merges:
- #73237 (Check for overflow in DroplessArena and align returned memory)
- #73339 (Don't run generator transform when there's a TyErr)
- #73372 (Re-order correctly the sections in the sidebar)
- #73373 (Use track caller for bug! macro)
- #73380 (Add more info to `x.py build --help` on default value for `-j JOBS`.)
- #73381 (Fix typo in docs of std::mem)
- #73389 (Use `Ipv4Addr::from<[u8; 4]>` when possible)
- #73400 (Fix forge-platform-support URL)
Failed merges:
r? @ghost
|
|
r=Mark-Simulacrum
Add more info to `x.py build --help` on default value for `-j JOBS`.
|
|
Avoid prematurely recording toolstates
When we're running with dry_run enabled (i.e. all builds do this initially), we're
guaranteed to save of a toolstate of TestFail for tools that aren't tested. In practice,
we do test tools as well, so for those tools we would initially record them as being
TestPass, and then later on re-record the correct state after actually testing them.
However, this would not work well if the build failed for whatever reason (e.g. panicking
in bootstrap, or as was the case in #73097, clippy failing to test successfully), we would
just go on believing that things passed when they in practice did not.
This commit also adjusts saving toolstate to never record clippy explicitly (otherwise, it
would be recorded when building it); eventually that'll likely move to other tools as well
but not yet. This is deemed simpler than checking everywhere we generically save
toolstate.
We also move clippy out of the "toolstate" no-fail-fast build into a separate x.py
invocation; this should no longer be technically required but provides the nice state of
letting us check toolstate for all tools and only then check clippy (giving full results
on every build).
r? @oli-obk
Supercedes #73275, also fixes #73274
|
|
This commit modifies bootstrap so that `config.toml` is read first from
`RUST_BOOTSTRAP_CONFIG`, then `--config` and finally `config.toml` in the
current directory.
This is a subjective change, intended to improve the ergnomics when
using "development shells" for rustc development (for example, using tools
such as Nix) which set environment variables to ensure a reproducible
environment (these development shells can then be version controlled). By
optionally reading `config.toml` from an environment variable, a `config.toml`
can be defined in the development shell and a path to it exposed in the
`RUST_BOOTSTRAP_CONFIG` environment variable - avoiding the need to manually
symlink the contents of this file to `config.toml` in the working
directory.
Signed-off-by: David Wood <david@davidtw.co>
|
|
|
|
|
|
When we're running with dry_run enabled (i.e. all builds do this initially), we're
guaranteed to save of a toolstate of TestFail for tools that aren't tested. In practice,
we do test tools as well, so for those tools we would initially record them as being
TestPass, and then later on re-record the correct state after actually testing them.
However, this would not work well if the build failed for whatever reason (e.g. panicking
in bootstrap, or as was the case in 73097, clippy failing to test successfully), we would
just go on believing that things passed when they in practice did not.
This commit also adjusts saving toolstate to never record clippy explicitly (otherwise, it
would be recorded when building it); eventually that'll likely move to other tools as well
but not yet. This is deemed simpler than checking everywhere we generically save
toolstate.
We also move clippy out of the "toolstate" no-fail-fast build into a separate x.py
invocation; this should no longer be technically required but provides the nice state of
letting us check toolstate for all tools and only then check clippy (giving full results
on every build).
|
|
PR #49778 introduced fs::canonicalize() which fails for a nonexistent path.
This is a surprise for someone used to GNU Autotools' configure which can create any necessary intermediate directories in prefix.
This change makes it run fs::create_dir_all() before canonicalize().
|
|
Implement new gdb/lldb pretty-printers
Reopened #60826
This PR replaces current gdb and lldb pretty-printers with new ones that were originally written for [IntelliJ Rust](https://github.com/intellij-rust/intellij-rust/tree/master/prettyPrinters).
The current state of lldb pretty-printers is poor, because [they don't use synthetic children](https://github.com/rust-lang/rust/issues/55586#issuecomment-436610063). When I started to reimplement lldb pretty-printers with synthetic children support, I've found current version strange and hard to support. I think `debugger_pretty_printers_common.py` is overkill, so I got rid of it.
The new pretty-printers have to support all types supported by current pretty-printers, and also support `Rc`, `Arc`, `Cell`, `Ref`, `RefCell`, `RefMut`, `HashMap`, `HashSet`.
Fixes #56252
|
|
Remove vestigial CI job msvc-aux.
This CI job isn't really doing anything, so it seems prudent to remove it.
For some history:
* This was introduced in #48809 when the msvc job was split in two to keep it under 2 hours (oh the good old days). At the time, this check-aux job did a bunch of things:
* tidy
* src/test/pretty
* src/test/run-pass/pretty
* src/test/run-fail/pretty
* src/test/run-pass-valgrind/pretty
* src/test/run-pass-fulldeps/pretty
* src/test/run-fail-fulldeps/pretty
* Tidy was removed in #60777.
* run-pass and run-pass-fulldeps moved to UI in #63029
* src/test/pretty removed in #58140
* src/test/run-fail moved to UI in #71185
* run-fail-fulldeps removed in #51285
Over time through attrition, the job was left with one lonely thing: `src/test/run-pass-valgrind/pretty`. And of course, this wasn't actually running the "pretty" tests. The normal `run-pass-valgrind` tests ran, and then when it tried to run in "pretty" mode, all the tests were ignored because compiletest thought nothing had changed (apparently compiletest isn't fingerprinting the mode? Needs more investigation…). `run-pass-valgrind` is already being run as part of `x86_64-msvc-1`, so there's no need to run it here.
I've taken the liberty of removing `src/test/run-pass-valgrind/pretty` as a distinct test. I'm guessing from the other PR's that the pretty tests should now live in `src/test/pretty`, and that the team has moved away from doing pretty tests on other parts of the `src/test` tree.
|
|
|
|
|
|
This should run much faster.
There are also some drive-by cleanups here to try to simplify things.
Also, the paths for in-tree crates are now displayed as relative
in `x.py test -h -v`.
|
|
x.py: do not build Miri by default on stable/beta
Fixes https://github.com/rust-lang/rust/issues/73117
Do I need to do anything to make sure Miri is still built by the tools CI builder? Are there other tools that should be off-by-default?
Also, unfortunately the `DEFAULT` associated const has no doc comment, so I have no idea what it does, or why there are semmingly two places where the default build of tools is controlled.
|
|
|
