Update cdb annotations for some debuginfo tests with cdb `10.0.26100.2161`
GitHub CI runners [recently updated to Windows Server 2022 (20241113)](https://github.com/actions/runner-images/releases/tag/win22%2F20241113.3) which included Windows Software Development Kit version `10.1.26100.1742`, which transitively shipped a `cdb` version `10.0.26100.2161`.
This changed some cdb output, causing 3 debuginfo tests to fail (see #133107, https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/msvc.20update.20causing.20debuginfo.20failures):
```
tests\debuginfo\numeric-types.rs
tests\debuginfo\range-types.rs
tests\debuginfo\unit-type.rs
```
I updated cdb annotations for these 3 tests locally with a matching `cdb` version. However, I am not by any means a cdb expert nor debuginfo expert, I just reblessed the tests to match whatever the new cdb version produces to unblock the tree. It is certainly possible that debuginfo improved/regressed/both with the newer cdb version.
try-job: x86_64-msvc
This is to unblock the tree, a proper fix will need to be investigated.
I think the debuginfo test suite supports revisions, however debugger
directives do not respect such revisions, which is problematic.
It's that 32-bit and 64-bit msvc of course have different integer widths
for `isize` and `usize`, meaning their underlying integer is different
and thus printed differently.
Rollup of 5 pull requests
Successful merges:
- #132936 (For expr `return (_ = 42);` unused_paren lint should not be triggered)
- #132956 (Add visit_coroutine_kind to ast::Visitor)
- #132978 (Mention both release *and* edition breakage for never type lints)
- #133074 (make UI test OS-agnostic)
- #133080 (Fix span edition for 2024 RPIT coming from an external macro )
r? `@ghost`
`@rustbot` modify labels: rollup
Fix span edition for 2024 RPIT coming from an external macro
This fixes a problem where code generated by an external macro with an RPIT would end up using the call-site edition instead of the macro's edition for the RPIT. When used from a 2024 crate, this caused the code to change behavior to the 2024 capturing rules, which we don't want.
This was caused by the impl-trait lowering code would replace the span with one marked with `DesugaringKind::OpaqueTy` desugaring. However, it was also overriding the edition of the span with the edition of the local crate. Instead it should be using the edition of the span itself.
Fixes https://github.com/rust-lang/rust/issues/132917
make UI test OS-agnostic
the internal representation of `std::sync::Mutex` depends on the compilation target. due to this, the compiler produces different number of errors for UI test `issue-17431-6.rs` depending on the compilation target.
for example, when compiling the UI test to an `*-apple-*` or `*-qnx7*` target, the "cycle detected" error is not reported
``` console
$ cat src/lib.rs
use std::sync::Mutex;
enum Foo {
X(Mutex<Option<Foo>>),
}
impl Foo {
fn bar(self) {}
}
fn main() {}
$ cargo check --target x86_64-apple-ios 2>&1 | rg '^error\['
error[E0072]: recursive type `Foo` has infinite size
```
whereas rustc produces two errors for other OSes, like Linux, which is what the UI test expects
``` console
$ cargo check --target x86_64-unknown-linux-gnu 2>&1 | rg '^error\['
error[E0072]: recursive type `Foo` has infinite size
error[E0391]: cycle detected when computing when `Foo` needs drop
```
this commit replaces the problematic `Mutex` with `UnsafeCell`, which has the same internal representation regardless of the compilation target. with that change, rustc reports two errors for all compilation targets.
``` console
$ cat src/lib.rs
use std::cell::UnsafeCell;
enum Foo {
X(UnsafeCell<Option<Foo>>),
}
impl Foo {
fn bar(self) {}
}
fn main() {}
$ cargo check --target x86_64-apple-ios 2>&1 | rg '^error\['
error[E0072]: recursive type `Foo` has infinite size
error[E0391]: cycle detected when computing when `Foo` needs drop
```
with this change, we can remove the `ignore-apple` directive as the UI test now also passes on apple targets.
Mention both release *and* edition breakage for never type lints
This PR makes ~~two changes~~ a change to the never type lints (`dependency_on_unit_never_type_fallback` and `never_type_fallback_flowing_into_unsafe`):
1. Change the wording of the note to mention that the breaking change will be made in an edition _and_ in a future release
2. ~~Make these warnings be reported in deps (hopefully the lints are matured enough)~~
r? ``@compiler-errors``
cc ``@ehuss``
closes#132930
Rollup of 4 pull requests
Successful merges:
- #132817 (Recurse into APITs in `impl_trait_overcaptures`)
- #133021 (Refactor `configure_annotatable`)
- #133045 (tests: Test pac-ret flag merging on clang with LTO)
- #133049 (Change Visitor::visit_precise_capturing_arg so it returns a Visitor::Result)
r? `@ghost`
`@rustbot` modify labels: rollup
This fixes a problem where code generated by an external macro with an
RPIT would end up using the call-site edition instead of the macro's
edition for the RPIT. When used from a 2024 crate, this caused the code
to change behavior to the 2024 capturing rules, which we don't want.
This was caused by the impl-trait lowering code would replace the span
with one marked with `DesugaringKind::OpaqueTy` desugaring. However, it
was also overriding the edition of the span with the edition of the
local crate. Instead it should be using the edition of the span itself.
Fixes https://github.com/rust-lang/rust/issues/132917
tests: Test pac-ret flag merging on clang with LTO
Extend the test for pac-ret with clang and LTO by checking that different branch protection flags are preserved after the LTO step. There was an issue in older LLVM versions that was causing this to behave incorrectly.
try-job: aarch64-gnu-debug
Recurse into APITs in `impl_trait_overcaptures`
We were previously not detecting cases where an RPIT was located in the return type of an async function, leading to underfiring of the `impl_trait_overcaptures`. This PR does this recursion properly now.
cc https://github.com/rust-lang/rust/issues/132809
check_consts: fix error requesting feature gate when that gate is not actually needed
When working on https://github.com/rust-lang/hashbrown/pull/586 I noticed that the compiler asks for the `rustc_private` feature to be enabled if one forgets to set `rustc_const_stable_indirect` on a function -- but enabling `rustc_private` would not actually help. This fixes the diagnostics.
r? `@compiler-errors`
the internal representation of `std::sync::Mutex` depends on the compilation target. due to this,
the compiler produces different number of errors for UI test
`issue-17431-6.rs` depending on the compilation target.
for example, when compiling the UI test to an `*-apple-*` or `*-qnx7*` target, the "cycle detected"
error is not reported
``` console
$ cat src/lib.rs
use std::sync::Mutex;
enum Foo {
X(Mutex<Option<Foo>>),
}
impl Foo {
fn bar(self) {}
}
fn main() {}
$ cargo check --target x86_64-apple-ios 2>&1 | rg '^error\['
error[E0072]: recursive type `Foo` has infinite size
```
whereas rustc produces two errors for other OSes, like Linux, which is what the UI test expects
``` console
$ cargo check --target x86_64-unknown-linux-gnu 2>&1 | rg '^error\['
error[E0072]: recursive type `Foo` has infinite size
error[E0391]: cycle detected when computing when `Foo` needs drop
```
this commit replaces the problematic `Mutex` with `UnsafeCell`, which has the same internal
representation regardless of the compilation target. with that change, rustc reports two errors for
all compilation targets.
``` console
$ cat src/lib.rs
use std::cell::UnsafeCell;
enum Foo {
X(UnsafeCell<Option<Foo>>),
}
impl Foo {
fn bar(self) {}
}
fn main() {}
$ cargo check --target x86_64-apple-ios 2>&1 | rg '^error\['
error[E0072]: recursive type `Foo` has infinite size
error[E0391]: cycle detected when computing when `Foo` needs drop
```
with this change, we can remove the `ignore-apple` directive as the UI test now also passes on apple
targets.
Extend the test for pac-ret with clang and LTO by checking that
different branch protection flags are preserved after the LTO step.
There was an issue in older LLVM versions that was causing this to
behave incorrectly.
Tests the LLVM behaviour added in:
1782810b84
rustc_metadata: Preprocess search paths for better performance
Over in Zed we've noticed that loading crates for a large-ish workspace (~100 members of workspace, over 1000 crates being built for the main binary target) can take almost 200ms. We've pinned it down to how rustc searches for paths to dependency files, as it performs a linear search over the list of candidate paths. In our case the candidate list had about 20k entries which we had to iterate over for each dependency being loaded. Our workspace is also pretty bottom-heavy, e.g. most of the workspace members pull in most of the transitive dependencies one way or another, which means that we spend quite some time loading crates at rustc startup.
This commit introduces a simple FilesIndex that's just a BTreeMap under the hood. Since crates are looked up by both prefix and suffix, we perform a range search on said BTree (which constraints the search space based on prefix) and follow up with a linear scan of entries with matching suffixes.
Overall, this commit brings down build time for us in dev scenarios by about 6%. 100ms might not seem like much, but this is a constant cost that each of our workspace crates has to pay, even when said crate is miniscule.
Over in Zed we've noticed that loading crates for a large-ish workspace can take almost 200ms. We've pinned it down to how rustc searches for paths, as it performs a linear search over the list of candidate paths. In our case the candidate list had about 20k entries which we had to iterate over for each dependency being loaded.
This commit introduces a simple FilesIndex that's just a sorted Vec under the hood. Since crates are looked up by both prefix and suffix, we perform a range search on said Vec (which constraints the search space based on prefix) and follow up with a linear scan of entries with matching suffixes.
FilesIndex is also pre-filtered before any queries are performed using available target information; query prefixes/sufixes are based on the target we are compiling for, so we can remove entries that can never match up front.
Overall, this commit brings down build time for us in dev scenarios by about 6%.
100ms might not seem like much, but this is a constant cost that each of our workspace crates has to pay, even when said crate is miniscule.
Rollup of 8 pull requests
Successful merges:
- #132790 (Add as_slice/into_slice for IoSlice/IoSliceMut.)
- #132905 ([AIX] Add crate "unwind" to link with libunwind)
- #132977 (Fix compilation error on Solaris due to flock usage)
- #132984 ([illumos] use pipe2 to create anonymous pipes)
- #133019 (docs: Fix missing period and colon in methods for primitive types)
- #133048 (use `&raw` in `{read, write}_unaligned` documentation)
- #133050 (Always inline functions signatures containing `f16` or `f128`)
- #133053 (tests: Fix the SIMD FFI tests with certain x86 configuration)
r? `@ghost`
`@rustbot` modify labels: rollup
tests: Fix the SIMD FFI tests with certain x86 configuration
This pull request fixes the SIMD FFI tests with certain x86 configurations by gating the SSE2 intrinsic behind the `sse2` feature gate. A generic LLVM intrinsic that is easy to un-fuse on those platforms is added to compensate for those platforms.
Always inline functions signatures containing `f16` or `f128`
There are a handful of tier 2 and tier 3 targets that cause a LLVM crash or linker error when generating code that contains `f16` or `f128`. The cranelift backend also does not support these types. To work around this, every function in `std` or `core` that contains these types must be marked `#[inline]` in order to avoid sending any code to the backend unless specifically requested.
However, this is inconvenient and easy to forget. Introduce a check for these types in the frontend that automatically inlines any function signatures that take or return `f16` or `f128`.
Note that this is not a perfect fix because it does not account for the types being passed by reference or as members of aggregate types, but this is sufficient for what is currently needed in the standard library.
Fixes: https://github.com/rust-lang/rust/issues/133035
Closes: https://github.com/rust-lang/rust/pull/133037
[illumos] use pipe2 to create anonymous pipes
pipe2 allows the newly-created pipe to atomically be CLOEXEC.
pipe2 was added to illumos a long time ago:
5dbfd19ad5. I've verified that this change passes all of std's tests on illumos.
Fix compilation error on Solaris due to flock usage
PR 130999 added the file_lock feature, but libc does not define flock() for the Solaris platform leading to a compilation error.
Additionally, I went through all the Tier 2 platforms and read through their documentation to see whether flock was implemented. This turned up 5 more Unix platforms where flock is not supported, even though it may exist in the libc crate.
Fixes https://github.com/rust-lang/rust/issues/132921
Related to #130999
[AIX] Add crate "unwind" to link with libunwind
The Rust on IBM AIX uses LLVM's `libunwind`. Since crate `unwind` is a dependency of crate `std` and `#![no_std]` is specified in the test case, `libunwind` is not included in the link command by default. As a result, the test case fails to link with the error "Undefined symbol: ._Unwind_Resume" on AIX. This PR explicitly adds crate `unwind` for AIX, along with feature `panic_unwind`, which is required to include the `unwind` crate.
There are a handful of tier 2 and tier 3 targets that cause a LLVM crash
or linker error when generating code that contains `f16` or `f128`. The
cranelift backend also does not support these types. To work around
this, every function in `std` or `core` that contains these types must
be marked `#[inline]` in order to avoid sending any code to the backend
unless specifically requested.
However, this is inconvenient and easy to forget. Introduce a check for
these types in the frontend that automatically inlines any function
signatures that take or return `f16` or `f128`.
Note that this is not a perfect fix because it does not account for the
types being passed by reference or as members of aggregate types, but
this is sufficient for what is currently needed in the standard library.
Fixes: https://github.com/rust-lang/rust/issues/133035
Closes: https://github.com/rust-lang/rust/pull/133037
These types are currently passed by reference, which does not avoid the
backend crashes. Change these back to being passed by value, which makes
the types easier to detect for automatic inlining.
[rustdoc] Fix handling of footnote reference in footnote definition
Fixes https://github.com/rust-lang/rust/issues/131946.
We didn't check if we had footnote reference in footnote definition.
r? `@notriddle`
Skip locking span interner for some syntax context checks
- `from_expansion` now never needs to consult the interner
- `eq_ctxt` now only needs the interner when both spans are fully interned
