- 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']
```
- Switch TypeId to 128 bits
- Hack around the fact that tracing-subscriber dislikes how TypeId is hashed
- Remove lowering of type_id128 from rustc_codegen_llvm
- Remove unnecessary `type_id128` intrinsic (just change return type of `type_id`)
- Only hash the lower 64 bits of the TypeId
- Reword comment
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.
