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.
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`
Fix drop scopes problems in mir
Fix false positives of `need-mut` emerged from #14955
There are still 5 `need-mut` false positives on self, all related to `izip!` macro hygenic issue. I will try to do something about that before monday release.
Rollup of 7 pull requests
Successful merges:
- #111659 (suggest `Option::as_deref(_mut)` on type mismatch in option combinator if it passes typeck)
- #111702 (Option::map_or_else: Show an example of integrating with Result)
- #111878 (Fix codegen test suite for bare-metal-like targets)
- #111969 (bootstrap: Make `clean` respect `dry-run`)
- #111998 (Add other workspaces to `linkedProjects` in rust_analyzer_settings)
- #112215 (only suppress coercion error if type is definitely unsized)
- #112231 (Make sure the build.rustc version is either the same or 1 apart (revised))
r? `@ghost`
`@rustbot` modify labels: rollup
only suppress coercion error if type is definitely unsized
we previously suppressed coercion errors when the return type was `dyn Trait` because we expect a far more descriptive `Sized` trait error to be emitted instead, however the code that does this suppression does not consider where-clause predicates since it just looked at the HIR. let's do that instead by creating an obligation and checking if it may hold.
fixes#110683fixes#112208
Add other workspaces to `linkedProjects` in rust_analyzer_settings
This makes go-to-definition, etc. work in cg_clif, cg_gcc, rust-analyzer, and src/tools/x.
Fix codegen test suite for bare-metal-like targets
For Ferrocene I needed to run the test suite for custom target with no unwinding and static relocation. Running the tests uncovered ~20 failures due to the test suite not accounting for these options. This PR fixes them by:
* Fixing `CHECK`s to account for functions having extra LLVM IR attributes (in this case `nounwind`).
* Fixing `CHECK`s to account for the `dso_local` LLVM IR modifier, which is [added to every item when relocation is static](f3d597b31c/compiler/rustc_codegen_llvm/src/mono_item.rs (L139-L142)).
* Fixing `CHECK`s to account for missing `uwtables` attributes.
* Added the `needs-unwind` attributes for tests that are designed to check unwinding.
There is no part of Rust CI that checks this unfortunately, and testing whether the PR works locally is kinda hard because you need a target with std enabled but no unwinding and static relocations. Still, this works in my local testing, and if future PRs accidentally break this Ferrocene will take care of sending followup PRs.
Option::map_or_else: Show an example of integrating with Result
Moving this from https://github.com/rust-lang/libs-team/issues/59 where an API addition was rejected. But I think it's valuable to add this example to the documentation at least.
suggest `Option::as_deref(_mut)` on type mismatch in option combinator if it passes typeck
Fixes#106342.
This adds a suggestion to call `.as_deref()` (or `.as_deref_mut()` resp.) if typeck fails due to a type mismatch in the function passed to an `Option` combinator such as `.map()` or `.and_then()`.
For example:
```rs
fn foo(_: &str) {}
Some(String::new()).map(foo);
```
The `.map()` method requires its argument to satisfy `F: FnOnce(String)`, but it received `fn(&str)`, which won't pass. However, placing a `.as_deref()` before the `.map()` call fixes this since `&str == &<String as Deref>::Target`
