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.
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.
Use the built cargo for cargotest.
cargotest was using the beta (bootstrap) cargo. This changes it so that it will use the locally built cargo. This is intended to provide a sort of smoke test to ensure Cargo is functional. This *shouldn't* have any real impact on the CI build time. The cargotest job also happens to run cargo's testsuite, so it should already be building cargo.
Note: This will fail until #73266 is merged.
Enable AVR as a Tier 3 target upstream
Tracking issue: #44052.
Things intentionally left out of the initial upstream:
* The `target_cpu` flag
I have made the cleanup suggestions by @jplatte and @jplatte in 043550d9db.
Anybody feel free to give the branch a test and see how it fares, or make suggestions on the code patch itself.
Try_run must only be used if toolstate is populated
Clippy's tests were failing the build, but that failure was ignored in favor of checking toolstate. This is the correct behavior for toolstate-checked tools, but Clippy no longer updates its toolstate status as it should always build.
The previous PR of this kind didn't catch this as I expected x.py failures to always lead to a non-successful build in CI, but that's not the case specifically for tool testing.
Replace old GDB and LLDB pretty-printers with new ones
which were originally written for IntelliJ Rust.
New LLDB pretty-printers support synthetic children.
New GDB/LLDB pretty-printers support all Rust types
supported by old pretty-printers, and also support:
Rc, Arc, Cell, Ref, RefCell, RefMut, HashMap, HashSet.
Clippy's tests were failing the build, but that failure was ignored in favor of
checking toolstate. This is the correct behavior for toolstate-checked tools,
but Clippy no longer updates its toolstate status as it should always build.
Count the beta prerelease number just from master
We were computing a merge-base between the remote beta and master
branches, but this was giving incorrect answers for the first beta if
the remote hadn't been pushed yet. For instance, `1.45.0-beta.3359`
corresponds to the number of merges since the 1.44 beta, but we really
want just `.1` for the sole 1.45 beta promotion merge.
We don't really need to query the remote beta at all -- `master..HEAD`
suffices if we assume that we're on the intended beta branch already.
We were computing a merge-base between the remote beta and master
branches, but this was giving incorrect answers for the first beta if
the remote hadn't been pushed yet. For instance, `1.45.0-beta.3359`
corresponds to the number of merges since the 1.44 beta, but we really
want just `.1` for the sole 1.45 beta promotion merge.
We don't really need to query the remote beta at all -- `master..HEAD`
suffices if we assume that we're on the intended beta branch already.
Make remote-test-client and remote-test-server compatible with windows
`compiletest` and `remote-test-client`:
The command line for `remote-test-client` was changed slightly to allow cross-platform compatible paths. The old way of supplying the support libs was by joining their paths with the executable path
with `:`. This caused Windows-style paths to be split after the directory letter. Now, the number of support libs is provided as a parameter as well, and the support lib paths are split off from the regular args in the client.
`remote-test-server`:
- Marked Unix-only parts as such and implemented Windows alternatives
- On Windows `LD_LIBRARY_PATH` doesn't exist. Libraries are loaded from `PATH` though, so that's the way around it.
- Tiny cleanup: `Command::args`/`envs` instead of manually looping over them
- The temp path for Windows has to be set via environment variable, since there isn't a global temp directory that would work on every machine (as a static string)
Update Clippy, RLS, and rustfmt
r? @Dylan-DPC
This makes Clippy test-pass again: 3089c3b
Otherwise this includes bugfixes and a few new lints.
Fixes#72231Fixes#72232
Since rustc-ap-* v659 we now need to set CFG_RELEASE for
rustc-ap-rustc_attr for `#[cfg(version(...))]` to work.
Co-authored-by: Eric Huss <ehuss@users.noreply.github.com>
This just unwraps clippy's build step instead of skipping tests if clippy didn't
build. This matches e.g. cargo's behavior and seems more correct, as we always
expect clippy to successfully build.
On my machine, an error looks like:
Finished release [optimized] target(s) in 0.29s
Opening doc /git/rust/build/x86_64-unknown-linux-gnu/doc/std/index.html
command 'xdg-open (internal)' did not execute successfully; exit code: 4
command stderr:
gio: file:///git/rust/build/x86_64-unknown-linux-gnu/doc/std/index.html: Error when getting information for file “/git/rust/build/x86_64-unknown-linux-gnu/doc/std/index.html”: No such file or directory
Build completed successfully in 0:00:08
Move the target libLLVM to llvm-tools-preview
For running the compiler, we usually only need LLVM from `$sysroot/lib`,
which rustup will make available with `LD_LIBRARY_PATH`. We've also been
shipping LLVM in the `$target/lib` directory, which bloats the download
and installed size. The only times we do need the latter are for the
RPATH of `llvm-tools-preview` binaries, and for linking `rustc-dev`
libraries. We'll move it to the `llvm-tools-preview` component directly,
and `rustc-dev` will have an implicit dependency on it.
Here are the dist sizes that I got before and after this change:
llvm-tools-1.45.0-dev-x86_64-unknown-linux-gnu.tar.gz 1.3M 24M
llvm-tools-1.45.0-dev-x86_64-unknown-linux-gnu.tar.xz 748K 17M
rustc-1.45.0-dev-x86_64-unknown-linux-gnu.tar.gz 83M 61M
rustc-1.45.0-dev-x86_64-unknown-linux-gnu.tar.xz 56M 41M
The installed size should reduce by exactly one `libLLVM.so` (~70-80M),
unless you also install `llvm-tools`, and then it should be identical.
Resolves#70838.
For running the compiler, we usually only need LLVM from `$sysroot/lib`,
which rustup will make available with `LD_LIBRARY_PATH`. We've also been
shipping LLVM in the `$target/lib` directory, which bloats the download
and installed size. The only times we do need the latter are for the
RPATH of `llvm-tools-preview` binaries, and for linking `rustc-dev`
libraries. We'll move it to the `llvm-tools-preview` component directly,
and `rustc-dev` will have an implicit dependency on it.
Here are the dist sizes that I got before and after this change:
llvm-tools-1.45.0-dev-x86_64-unknown-linux-gnu.tar.gz 1.3M 24M
llvm-tools-1.45.0-dev-x86_64-unknown-linux-gnu.tar.xz 748K 17M
rustc-1.45.0-dev-x86_64-unknown-linux-gnu.tar.gz 83M 61M
rustc-1.45.0-dev-x86_64-unknown-linux-gnu.tar.xz 56M 41M
The installed size should reduce by exactly one `libLLVM.so` (~70-80M),
unless you also install `llvm-tools`, and then it should be identical.
linker: More systematic handling of CRT objects
Document which kinds of `crt0.o`-like objects we link and in which cases, discovering bugs in process.
`src/librustc_target/spec/crt_objects.rs` is the place to start reading from.
This PR also automatically contains half of the `-static-pie` support (https://github.com/rust-lang/rust/pull/70740), because that's one of the six cases that we need to consider when linking CRT objects.
This is a breaking change for custom target specifications that specify CRT objects.
Closes https://github.com/rust-lang/rust/issues/30868
Forbid stage arguments to check
Users generally expect that check builds are fast, and that's only true in stage
0 (stages beyond that need us to build a compiler, which is slow).
Closes#69337
r? @alexcrichton
Provide separate option for std debug asserts
On local one-off benchmarking of libcore metadata-only, debug asserts in std are a significant hit (15s to 20s). Provide an option for compiler developers to disable them. A build with a nightly compiler is around 10s, for reference.
Fix bootstrap failing on win32
```powershell
python x.py -h # or really any x.py command
```
would fail with
```
info: Downloading and building bootstrap before processing --help
command. See src/bootstrap/README.md for help with common
commands.
Updating only changed submodules
Submodules updated in 0.15 seconds
Traceback (most recent call last):
File "x.py", line 11, in <module>
bootstrap.main()
File "C:\Users\Joshua\Projects\forks\rust\src\bootstrap\bootstrap.py", line 960, in main
bootstrap(help_triggered)
File "C:\Users\Joshua\Projects\forks\rust\src\bootstrap\bootstrap.py", line 925, in bootstrap
build.build = args.build or build.build_triple()
File "C:\Users\Joshua\Projects\forks\rust\src\bootstrap\bootstrap.py", line 731, in build_triple
return default_build_triple()
File "C:\Users\Joshua\Projects\forks\rust\src\bootstrap\bootstrap.py", line 184, in default_build_triple
ostype = require(["uname", "-s"], exit=required).decode(default_encoding)
AttributeError: 'NoneType' object has no attribute 'decode'
```
This PR defers the `decode` call until after we're sure `ostype` and `cputype` are not `None`, as they would be on Windows since `uname` doesn't exist
bootstrap: remove lldb dist packaging
The lldb-preview rustup package is missing on every single target, and has never been shipped beyond x86_64-apple-darwin. It was removed in #62592 which landed around a year ago, and there's not been demand that we re-enable it since, so we're now removing support entirely to cleanup the code a bit.
The hope is that this will also kill the useless "lldb-preview" row on https://rust-lang.github.io/rustup-components-history/.
This allows configuring the directory for build artifacts, instead of having it always be ./build. This means you can set it to a constant location, letting you reuse the same cache while working in several different directories.
The configuration lives in config.toml under build.build-dir. By default, it keeps the existing default of ./build, but it can be configured to any relative or absolute path. Additionally, it allows making outputs relative to the root of the git repository using $ROOT.
