- Only add -gz if it's supported
- Don't include extra unnecessary debuginfo when only debuginfo-level=1 is set
- Compress debuginfo sections to reduce the size of debuginfo on disk.
before: 650 MB
line tables only: 335 MB
compressed only: 216 MB
compressed and line tables: 186 MB
no debuginfo at all: 130 MB
I want to investigate why `-C line-tables-only` is still ~tripling the
size of the binary, but this seems like a good improvement in the
meantime.
I've tested that both valgrind and perf can read the debuginfo:
```
(bash@dev-desktop-us-1.infra.rust-lang.org) ~/rust [08:31:08]
; valgrind $(rustup which rustc --toolchain rust_stage2) --version
==441671== Memcheck, a memory error detector
==441671== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==441671== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==441671== Command: /home/gh-jyn514/.local/lib/rustup/toolchains/rust_stage2/bin/rustc --version
==441671==
rustc 1.70.0-dev
==441671==
==441671== HEAP SUMMARY:
==441671== in use at exit: 231,289 bytes in 1,874 blocks
==441671== total heap usage: 2,538 allocs, 664 frees, 486,368 bytes allocated
==441671==
==441671== LEAK SUMMARY:
==441671== definitely lost: 70,656 bytes in 1 blocks
==441671== indirectly lost: 0 bytes in 0 blocks
==441671== possibly lost: 0 bytes in 0 blocks
==441671== still reachable: 160,633 bytes in 1,873 blocks
==441671== suppressed: 0 bytes in 0 blocks
==441671== Rerun with --leak-check=full to see details of leaked memory
==441671==
==441671== For lists of detected and suppressed errors, rerun with: -s
==441671== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
; perf record $(rustup which rustc --toolchain rust_stage2) --version
rustc 1.70.0-dev
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.005 MB perf.data (70 samples) ]
; perf report
Samples: 70 of event 'cycles:u', Event count (approx.): 21356967
Overhead Command Shared Object Symbol
51.55% rustc ld-linux-aarch64.so.1 [.] _dl_lookup_symbol_x
18.70% rustc ld-linux-aarch64.so.1 [.] _dl_relocate_object
11.95% rustc ld-linux-aarch64.so.1 [.] do_lookup_x
5.55% rustc [unknown] [k] 0xffffa9ad41cfcfdc
2.68% rustc libc.so.6 [.] __GI___strlen_asimd
2.42% rustc librustc_driver-1a385c366c35e81a.so [.] llvm::StringMapImpl::LookupBucketFor
2.16% rustc librustc_driver-1a385c366c35e81a.so [.] _GLOBAL__sub_I_X86InstructionSelector.cpp
1.96% rustc libstd-990fe978dab76ef3.so [.] <alloc::vec::Vec<T,A> as core::clone::Clone>::clone
1.60% rustc librustc_driver-1a385c366c35e81a.so [.] llvm:🆑:opt<bool, false, llvm:🆑:parser<bool> >::~opt
1.22% rustc ld-linux-aarch64.so.1 [.] strcmp
0.13% rustc ld-linux-aarch64.so.1 [.] stat64
0.05% rustc ld-linux-aarch64.so.1 [.] __minimal_calloc
0.02% rustc ld-linux-aarch64.so.1 [.] __GI___tunables_init
0.02% rustc ld-linux-aarch64.so.1 [.] _dl_start
0.00% rustc [unknown] [k] 0xffffa9ad41cfd844
0.00% rustc ld-linux-aarch64.so.1 [.] _start
```
Show note for type ascription on a local binding interpreted as a constant pattern and not a new variable
Given the code
```rust
pub fn main() {
const y: i32 = 4;
let y: i32 = 3;
}
```
`y` in the let binding is actually interpreted as a constant pattern and is not a new variable, causing confusing diagnostics about refutable patterns in local binding.
This PR extends the note for type ascription of a constant pattern to `AscribeUserType` patterns which have `Constant` subpatterns.
Fixes#112269.
Fix type-inference regression in #112225
The type inference of argument-position closures and async blocks regressed in 1.70 as the evaluation order of async blocks changed, as they are not implicitly wrapped in an identity-function anymore.
Fixes#112225 by making sure the evaluation order stays the same as it used to.
r? `@compiler-errors`
As this was a stable-to-stable regression, it might be worth to consider backporting. Although the workaround for this is trivial as well: Just wrap the async block in another block.
Rollup of 3 pull requests
Successful merges:
- #112247 (rust-lld: add rpath entry to the correct `lib` folder)
- #112274 (Migrate GUI colors test to original CSS color format)
- #112277 (Don't require the output from libtest to be valid UTF-8)
Failed merges:
- #112251 (rustdoc: convert `if let Some()` that always matches to variable)
r? `@ghost`
`@rustbot` modify labels: rollup
fix: consider outer binders when folding captured items' type
Fixes#14966
Basically, the crash is caused by us producing a broken type and passing it to chalk: `&dyn for<type> [for<> Implemented(^1.0: A<^0.0>)]` (notice the innermost bound var `^0.0` has no corresponding binder). It's created in `CapturedItemWithoutTy::with_ty()`, which didn't consider outer binders when folding types to replace placeholders with bound variables.
The fix is one-liner, but I've also refactored the surrounding code a little.
Don't require the output from libtest to be valid UTF-8
On Windows this is sometimes not the case, for reasons I can't track down (maybe related to localization? the bug report had a french locale).
This works around the problem, although I'm not sure how to confirm we're not generating invalid build metrics in this case.
Fixes https://github.com/rust-lang/rust/issues/112273.
Migrate GUI colors test to original CSS color format
Follow-up of https://github.com/rust-lang/rust/pull/111459.
The update for `browser-ui-test` version is because for hex color conversions, it used a precision of 1 instead of 2, which was problematic.
r? `@notriddle`
rust-lld: add rpath entry to the correct `lib` folder
An explanation, for our linux rustup toolchain:
- `lld` / `rust-lld` is built as a regular LLVM tool, but is not distributed via the `llvm-tools` component. It's distributed by default, like a regular rust binary, like cargo and rustc. The general expected setup is: binaries in `bin` and libraries in `lib`, so the rpath we use for a `bin/$executable` is `$ORIGIN/../lib`.
- However, `rust-lld` is _not_ in the same location as our other executables (`$root/bin`), it's in `$root/lib/rustlib/$host/bin/`. The current rpath thus expects the LLVM's shared library to be in `$root/lib/rustlib/$host/lib/`.
- That .so is only present in `$root/lib`, causing #80703. (LLVM's shared library is also copied to `$root/lib/rustlib/$host/lib/` with the `llvm-tools` component, so it also was [a workaround for the issue](https://github.com/rust-lang/rust/issues/80703#issuecomment-1574788504))
rustup's `LD_LIBRARY_PATH` overrides made this discrepancy invisible when we switched to `llvm.link-shared = true`, and this only showed up when running `rustc` or `rust-lld`'s executables directly.
To fix this we could:
- copy the .so to this expected location all the time, but that seems wasteful.
- or, add an rpath entry when building LLD, which seems preferable to me (but I don't know if it could cause issues).
This PR does the latter, tweaking how bootstrap builds LLD to point to the expected directory, and fixes#80703.
(Since this is related to P-high issues about switching to lld by default, I'll cc `@petrochenkov` to keep them updated.)
Print the full arguments passed to `./configure` in CI
This is useful to replicate CI failures locally. Before, the arguments would be truncated and it would be hard to tell what it was actually doing.
Before:
```
configure: build.configure-args := ['--build=x86_64-unknown-linux-gnu', '--save-t ...
```
After:
```
configure: build.configure-args := ['--build=x86_64-unknown-linux-gnu', '--save-toolstates=/tmp/toolstate/toolstates.json', '--enable-verbose', '--enable-sccache', '--disable-manage-submodules', '--enable-locked-deps', '--enable-cargo-native-static', '--set', 'rust.codegen-units-std=1', '--set', 'dist.compression-profile=balanced', '--dist-compression-formats=xz', '--disable-dist-src', '--set', 'rust.download-rustc=if-unchanged', '--release-channel=nightly', '--enable-debug-assertions', '--enable-overflow-checks', '--enable-llvm-assertions', '--set', 'rust.verify-llvm-ir', '--set', 'llvm.download-ci-llvm=if-available', '--enable-missing-tools']
```
On Windows this is sometimes not the case, for reasons I can't track down.
This works around the problem, although I'm not sure how to confirm we're not generating invalid
build metrics in this case.
Given the code
```rust
pub fn main() {
const y: i32 = 4;
let y: i32 = 3;
}
```
`y` in the let binding is actually interpreted as a constant pattern
and is not a new variable, causing confusing diagnostics about
refutable patterns in local binding.
This commit extends the note for type ascription as a constant pattern
to `AscribeUserType` patterns as well.
Fix bug where private item with intermediate doc hidden re-export was not inlined
This fixes this bug:
```rust
mod private {
/// Original.
pub struct Bar3;
}
/// Hidden.
#[doc(hidden)]
pub use crate::private::Bar3;
/// Visible.
pub use self::Bar3 as Reexport;
```
In this case, `private::Bar3` should be inlined and renamed `Reexport` but instead we have:
```
pub use self::Bar3 as Reexport;
```
and no links.
There were actually two issues: the first one is that we forgot to check if the next intermediate re-export was doc hidden. The second was that we made the `#[doc(hidden)]` attribute inheritable, which shouldn't be possible.
r? `@notriddle`
Revert "Enable incremental independent of stage"
This reverts commit 827f656ebb.
Incremental is not sound to use across stages. Arbitrary changes to the compiler can invalidate the incremental cache - even changes to normal queries, not incremental itself! - and we do not currently enable `incremental-verify-ich` in bootstrap. Since 2018, we highly recommend and nudge users towards stage 1 builds instead of stage 2, and using `keep-stage` for anything other than libstd is very rare.
I don't think the risk of unsoundness is worth the very minor speedup when building libstd. Disable incremental to avoid spurious panics and miscompilations when building with the stage 1 and 2 sysroot.
Combined with https://github.com/rust-lang/rust/pull/111329, this should fix https://github.com/rust-lang/rust/issues/76720.
r? `@Mark-Simulacrum`
Fix `x test core` when download-rustc is enabled
Fix `x test --stage 2 core` when download-rustc is enabled
This works by building std from source instead of downloading it, for library tests only.
This was somewhat complicated because of the following requirements:
1. Unconditionally downloading libstd breaks `x test core`, because `coretests` requires the std loaded from the sysroot to match the std that's currently being tested.
2. Unconditionally rebuilding libstd breaks `x test ui-fulldeps librustdoc`, because anything loading `rustc_private` needs to use the same libstd that rustc was built with.
Break the knot by introducing a new `stage2-test-sysroot`, used only for testing `std` itself. This
holds a freshly compiled std, while `stage2` and `ci-rustc-sysroot` still hold the downloaded std.
This also extends the existing `cp_filtered` in Sysroot to apply to the `rust-std` component, not just the `rustc-dev` component, to avoid having both versions of std in `stage2-test-sysroot`.
Fixes#110352.
add `#[doc(alias="flatmap")]` to `Option::and_then`
I keep forgetting that rust calls this `and_then` and trying to search for `flatmap`. `and_then`'s docs even mention "Some languages call this operation flatmap", but it doesn't show up as a result in the search at `https://doc.rust-lang.org/std/?search=flatmap`
- use `DefWithBodyId::as_generic_def_id()`
- add comments on `InferenceResult` invariant
- move local helper function to bottom to comply with style guide
The type inference of argument-position closures and async blocks
regressed in 1.70 as the evaluation order of async blocks changed, as
they are not implicitly wrapped in an identity-function anymore.
Fixes#112225 by making sure the evaluation order stays the same as it
used to.
Revert "Add mandatory panic contexts to all threadpool tasks"
Reverts rust-lang/rust-analyzer#14965
This won't quite work actually given the use of `catch_unwind` in some of these
Add mandatory panic contexts to all threadpool tasks
the diagnostics task is panicking I think, but without this you can't really tell because the stack trace ends in a generic iterator fold call instead of something specific.
Only check inlining counter after recursing.
This PR aims to reduce the strength of https://github.com/rust-lang/rust/pull/105119 even more.
In the current implementation, we check the inline count before recursing. This means that we never actually reach inlining depth 3.
This PR checks the counter after recursion, to give a chance to inline at depth >= 3.
r? `@scottmcm`
cc `@JakobDegen`
update Miri
Also adjust Miri's compiletest a little: in pre-subtree days we added `-A unused -Astable-features` to have the Miri toolstate break less often. But nowadays it just causes confusion when Miri CI works in rustc but fails on the Miri side so let's get rid of this difference.
r? `@oli-obk`
