Post-attribute ports cleanup pt. 1 (again)
This is a re-implementation of most (but not all) of https://github.com/rust-lang/rust/pull/154808
The code is the same as in that PR, other than a few changes, I'll leave comments where I changed things.
I did re-implement most of the commits rather than cherry-picking, so it's probably good to check the entire diff regardless
r? @jdonszelmann
Rollup of 3 pull requests
Successful merges:
- rust-lang/rust#152530 (Use the term struct-like variant instead of anonymous structs for data of struct-like enum variants)
- rust-lang/rust#155005 (preserve SIMD element type information)
- rust-lang/rust#155230 (Avoid linting `doc_cfg` as unused in rustc)
preserve SIMD element type information
Preserve the SIMD element type and provide it to LLVM for better optimization.
This is relevant for AArch64 types like `int16x4x2_t`, see also https://github.com/llvm/llvm-project/issues/181514. Such types are defined like so:
```rust
#[repr(simd)]
struct int16x4_t([i16; 4]);
#[repr(C)]
struct int16x4x2_t(pub int16x4_t, pub int16x4_t);
```
Previously this would be translated to the opaque `[2 x <8 x i8>]`, with this PR it is instead `[2 x <4 x i16>]`. That change is not relevant for the ABI, but using the correct type prevents bitcasts that can (indeed, do) confuse the LLVM pattern matcher.
This change will make it possible to implement the deinterleaving loads on AArch64 in a portable way (without neon-specific intrinsics), which means that e.g. Miri or the cranelift backend can run them without additional support.
discussion at [#t-compiler > loss of vector element type information](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/loss.20of.20vector.20element.20type.20information/with/584483611)
tidy: handle `#[cfg_attr(bootstrap, doc = "...")]` in `compiler/` comments
For the unbalanced backtick check that Waffle ran into in https://github.com/rust-lang/rust/pull/154887.
This PR cherry-picks Waffle's tidy patch in that PR (and adds some explaining comments) even though I'd say this is somewhat hacky[^1]. But since the original tidy check implementation is already based on heuristics and so are likewise fuzzy, this is probably fine in practice for most cases.
[^1]: There can be false positives/negatives like having both fragments `cfg_attr` and `doc` inside a string literal, but I would expect that to be very very niche, so it's "good enough".
(I wanted to write a regression test, but this check needs some restructuring to make it more easy to test that I don't want to bundle in this PR.)
r? wafflelapkin (or bootstrap/compiler)
Trait aliases: Also imply default trait bounds on type params other than `Self`
Trait aliases already correctly imply default trait bounds on `Self` type params. However, due to an oversight, they didn't do that for normal type params.
Fixesrust-lang/rust#152687.
Implement `-Z allow-partial-mitigations` (RFC 3855)
This implements `-Z allow-partial-mitigations` as an unstable option, currently with support for control-flow-guard and stack-protector.
As a difference from the RFC, we have `-Z allow-partial-mitigations=!foo` rather than `-Z deny-partial-mitigations=foo`, since I couldn't find an easy way to have an allow/deny pair of flags where the latter flag wins.
To allow for stabilization, this is only enabled starting from the next edition. Maybe a better policy is possible (bikeshed).
r? @rcvalle
Start using pattern types in libcore
cc rust-lang/rust#135996
Replaces the innards of `NonNull` with `*const T is !null`.
This does affect LLVM's optimizations, as now reading the field preserves the metadata that the field is not null, and transmuting to another type (e.g. just a raw pointer), will also preserve that information for optimizations. This can cause LLVM opts to do more work, but it's not guaranteed to produce better machine code.
Once we also remove all uses of rustc_layout_scalar_range_start from rustc itself, we can remove the support for that attribute entirely and handle all such needs via pattern types
Fix manpage version replacement and use verbose version
- Fix a bug where `t!(fs::copy(&page_src, &page_dst))` was called after`fs::write`, silently overwriting the substituted content with the original template (restoring the `<INSERT VERSION HERE>` placeholder verbatim) (Related rust-lang/rust#93685)
- Use `rust_info().version()` instead of the bare version number, so the man page now includes the full version string with commit hash and date
Improve emission of `UnknownDiagnosticAttribute` lint
This checks features much less than the current implementation. See https://github.com/rust-lang/rust/pull/155155 for context. Minor fixes and comments are added in the second and third commit.
Move tests from `tests/ui/issues/` to appropriate directories
In this PR, I am moving the following test from `tests/ui/issues` directory to the appropriate directories, followed by the addition of issue links at the top and reblessing of the stderr files:
| old-name | new-sub-dir | new-name |
|-|-|-|
| `issue-29516.rs` | `auto-traits/` | `distinct-type-tuple-by-negative-impl.rs` |
| `issue-3874.rs` | `binding/` | `ref-in-let-lhs-in-field.rs` |
| `issue-32782.rs` | `feature-gates/` | `feature-gate-check-nested-macro-invocation.rs` |
| `issue-32782.stderr` | `feature-gates/` | `feature-gate-check-nested-macro-invocation.stderr` |
| `issue-5100.rs` | `pattern/` | `match-errors-derived-error-suppression.rs` |
| `issue-5100.stderr` | `pattern/` | `match-errors-derived-error-suppression.stderr` |
| `issue-21033.rs` | `pattern/` | `match-struct-var-having-boxed-field.rs` |
r? Kivooeo
r? Teapot4195
UI automation
# To move issue-3154 and issue-16774 to functional subdirectories:
I have moved 2 tests from tests/ui/issues to their appropriate directories using "test-manager" tool.
## Changes:
- Moved tests/ui/issues/issue-3154.rs to tests/ui/borrowck/missing-lifetime-in-return.rs
- Moved tests/ui/issues/issue-16774.rs to tests/ui/deref/derefmut-closure-drop-order.rs
These moves where performed using the test-manager automation tool.
Small refactor of `arena_cache` query values
Query modifier `arena_cache` automatically allocates only `Some` variant of query's value of type `Option<&'tcx T>`, so `mir_callgraph_cyclic` should've been doing it from the beginning. The same could be said for any `Result<&'tcx T, ErrorGuaranteed>` as `ErrorGuaranteed` is a zero sized type, but that requires adding a new `ArenaCached` implementation.
Make `DerefPure` dyn-incompatible
Fixes https://github.com/rust-lang/rust/issues/154619.
If `DerefPure` were dyn-compatible, a trait object of a subtrait of `DerefPure` could be created by unsize-coercing an existing type that implements `DerefPure`. But then the trait object could have its own non-pure impl of `Deref`/`DerefMut`, which is unsound, since the trait object would implement `DerefPure`. Thus, we make `DerefPure` dyn-incompatible.
r? types
Add --verbose-run-make-subprocess-output flag to suppress verbose run-make output for passing tests
- Adds `--verbose-run-make-subprocess-output` flag to `./x test` and compiletest
- `./x test --no-capture --verbose-run-make-subprocess-output=false` suppresses verbose subprocess output for passing run-make tests
- Failed tests always print their output regardless of `--verbose-run-make-subprocess-output`
- Default behavior (verbose) is unchanged
This addresses the request from @bjorn3 which needs `--no-capture` (due to `panic=abort`) but doesn't want output dumped for every passing test.
Helps with rust-lang/rust#154069
## Test plan
- [x] `./x test tests/run-make/bare-outfile --no-capture --force-rerun` — verbose output for passing test
- [x] `./x test tests/run-make/bare-outfile --no-capture --verbose-run-make-subprocess-output=false --force-rerun` — no verbose output for passing test
- [x] Failing test still dumps output with `--verbose-run-make-subprocess-output=false`
cg_ssa: transmute between scalable vectors
Like regular SIMD vectors, we can support casting between scalable vectors of integral or floating-point types without needing a temporary.
r? @Amanieu
Normalize individual predicate of `InstantiatedPredicates` inside `predicates_for_generics`
This is a cleanup to better land rust-lang/rust#155083. It allows us to wrap individual clause in `Unnormalized` wrapper. See [this comment](https://github.com/rust-lang/rust/pull/155083#discussion_r3072219035)
Besides that, this PR also adds missing normalization in some cases.
r? @lcnr
Add more robust handling of nested query cycles
This adds more robust handling of query cycle that occur while we are already printing a query cycle error. Such nested query cycle are compiler bugs and this adds special handling so that both the nested query cycle and the outer query cycle are printed. Doubly nested query cycle errors are ignored to prevent infinite recursion.
Implement EII for statics
This PR implements EII for statics. I've tried to mirror the implementation for functions in a few places, this causes some duplicate code but I'm also not really sure whether there's a clean way to merge the implementations.
This does not implement defaults for static EIIs yet, I will do that in a followup PR
Fix thread::available_parallelism on WASI targets with threads
The refactoring in ba462864f1 ("std: Use more unix.rs code on WASI targets") moved WASI from its own thread module into the shared unix.rs module. However, it did not carry over the available_parallelism() implementation for WASI with threads, causing it to fall through to the unsupported catch-all. This silently regressed the support originally added in f0b7008648.
Fix this by adding WASI to the standard UNIX cfg_select branch.
Depends on rust-lang/rust#155057 (Update libc to v0.2.184).
Change codegen of LLVM intrinsics to be name-based, and add llvm linkage support for `bf16(xN)` and `i1xN`
*[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/pull/140763)*
This PR changes how LLVM intrinsics are codegen
# Explanation of the changes
## Current procedure
This is the same for all functions, LLVM intrinsics are _not_ treated specially
- We get the LLVM Type of a function simply using the argument types. For example, the following function
```rust
#[link_name = "llvm.sqrt.f32"]
fn sqrtf32(a: f32) -> f32;
```
will have LLVM type simply `f32 (f32)` due to the Rust signature
### Pros
- Simpler to implement, no extra complexity involved due to LLVM intrinsics
### Cons
- LLVM intrinsics have a well-defined signature, completely defined by their name (and if it is overloaded, the type parameters). So, this process of converting Rust signatures to LLVM signatures may not work, for example the following code generates LLVM IR without any problem
```rust
#[link_name = "llvm.sqrt.f32"]
fn sqrtf32(a: i32) -> f32;
```
but the generated LLVM IR is invalid, because it has wrong signature for the intrinsic ([Godbolt](https://godbolt.org/z/6ff9hrcd5), adding `-Zverify-llvm-ir` to it will fail compilation). I would expect this code to not compile at all instead of generating invalid IR.
- LLVM intrinsics that have types in their signature that can't be accessed from Rust (notable examples are the AMX intrinsics that have the `x86amx` type, and (almost) all intrinsics that have vectors of `i1` types) can't be linked to at all. This is a (major?) roadblock in the AMX and AVX512 support in stdarch.
- If code uses an non-existing LLVM intrinsic, even `-Zverify-llvm-ir` won't complain. Eventually it will error out due to the non-existing function (courtesy of the linker). I don't think this is a behavior we want.
## What this PR does
- When linking to **non-overloaded** intrinsics, we use the function `LLVMIntrinsicGetType` to directly get the function type of the intrinsic from LLVM.
- We then use this LLVM definition to _verify_ the Rust signature, and emit a proper error if it doesn't match, instead of silently emitting invalid IR.
- Lint if linking to deprecated or invalid LLVM intrinsics
> [!NOTE]
> This PR only focuses on non-overloaded intrinsics, overloaded can be done in a future PR
Regardless, the undermentioned functionalities work for **all** intrinsics
- If we can't find the intrinsic, we check if it has been `AutoUpgrade`d by LLVM. If not, that means it is an invalid intrinsic, and we error out.
- Don't allow intrinsics from other archs to be declared, e.g. error out if an AArch64 intrinsic is declared when we are compiling for x86
### Pros
- It is now not possible (or at least, it would require _significantly_ more leaps and bounds) to introduce invalid IR using **non-overloaded** LLVM intrinsics.
- As we are now doing the matching of Rust signatures to LLVM intrinsics ourselves, we can now add bypasses to enable linking to such non-Rust types (e.g. matching 8192-bit vectors to `x86amx` and injecting `llvm.x86.cast.vector.to.tile` and `llvm.x86.cast.tile.to.vector`s in callsite)
> [!NOTE]
> I don't intend for these bypasses to be permanent. A better approach will be introducing a `bf16` type in Rust, and allowing `repr(simd)` with `bool`s to get Rust-native `i1xN`s. These are meant to be short-time, as I mentioned, "bypass"es. They shouldn't cause any major breakage even if removed, as `link_llvm_intrinsics` is perma-unstable.
This PR adds bypasses for `bf16` (via `i16`), `bf16xN` (via `i16xN`) and `i1xN` (via `iM`, where `M` is the smallest power of 2 s.t. `M >= N`, unless `N <= 4`, where we use `M = 8`). This will unblock AVX512-VP2INTERSECT and a lot of bf16 intrinsics in stdarch. This PR also automatically destructures structs if the types don't exactly match (this is required for us to start emitting hard errors on mismmatches).
### Cons
- This only works for non-overloaded intrinsics (at least for now). Improving this to work with overloaded intrinsics too will involve significantly more work.
# Possible ways to extend this to overloaded intrinsics (future)
## Parse the mangled intrinsic name to get the type parameters
LLVM has a stable mangling of intrinsic names with type parameters (in `LLVMIntrinsicCopyOverloadedName2`), so we can parse the name to get the type parameters, and then just do the same thing.
### Pros
- For _most_ intrinsics, this will work perfectly, and is a easy way to do this.
### Cons
- The LLVM mangling is not perfectly reversible. When we have `TargetExt` types or identified structs, their name is a part of the mangling, making it impossible to reverse. Even more complexities arise when there are unnamed identified structs, as LLVM adds more mangling to the names.
- @nikic's work on LLVM intrinsics will remove the name mangling, making this approach impossible
## Use the `IITDescriptor` table and the Rust function signature
We can use the base name to get the `IITDescriptor`s of the corresponding intrinsic, and then manually implement the _matching_ logic based on the Rust signature.
### Pros
- Doesn't have the above mentioned limitation of the parsing approach, has correct behavior even when there are identified structs and `TargetExt` types. Also, fun fact, Rust exports all struct types as literal structs (unless it is emitting LLVM IR, then it always uses named identified structs, with mangled names)
### Cons
- **Doesn't** actually use the type parameters in the name, only uses the base name and the Rust signature to get the llvm signature (although we _can_ check that it is the correct name). It means there would be no way to (for example) link against `llvm.sqrt.bf16` until we have `bf16` types in Rust. Because if we are using `u16`s (or any other type) as `bf16`s, then the matcher will deduce that the signature is `u16 (u16)` not `bf16 (bf16)` (which would lead to an error because `u16` is not a valid type parameter for `llvm.sqrt`), even though the intended type parameter is specified in the name.
- Much more complex, and hard to maintain as LLVM gets new `IITDescriptorKind`s
These 2 approaches might give different results for same function. Let's take
```rust
#[link_name = "llvm.is.constant.bf16"]
fn foo(a: u16) -> bool
```
The name-based approach will decide that the type parameter is `bf16`, and the LLVM signature is `i1 (bf16)` and will inject some bitcasts at callsite.
The `IITDescriptor`-based approach will decide that the LLVM signature is `i1 (u16)`, and will see that the name given doesn't match the expected name (`llvm.is.constant.u16`), and will error out.
Reviews are welcome, as this is my first time _actually_ contributing to `rustc`
@rustbot label T-compiler A-codegen A-LLVM
r? codegen
Use closures more consistently in `dep_graph.rs`.
This file has several methods that take a `FnOnce() -> R` closure:
- `DepGraph::with_ignore`
- `DepGraph::with_query_deserialization`
- `DepGraph::with_anon_task`
- `DepGraphData::with_anon_task_inner`
It also has two methods that take a faux closure via an `A` argument and a `fn(TyCtxt<'tcx>, A) -> R` argument:
- DepGraph::with_task
- DepGraphData::with_task
The rationale is that the faux closure exercises tight control over what state they have access to. This seems silly when (a) they are passed a `TyCtxt`, and (b) when similar nearby functions take real closures. And they are more awkward to use, e.g. requiring multiple arguments to be gathered into a tuple. This commit changes the faux closures to real closures.
r? @Zalathar
Make the expansion of guard metavars begin guard non-terminals
While investigating something unrelated, I noticed a bug in the impl of unstable feature `macro_guard_matcher` (tracking issue: rust-lang/rust#153104). Namely, the following doesn't compile:
```rs
#![feature(macro_guard_matcher)]
macro_rules! a { ($guard:guard) => { b!($guard); }; }
macro_rules! b { ($guard:guard) => {}; }
a!(if true);
```
```
error: no rules expected `guard` metavariable
--> src/lib.rs:3:41
|
3 | macro_rules! a { ($guard:guard) => { b!($guard); }; }
| ^^^^^^ no rules expected this token in macro call
4 | macro_rules! b { ($guard:guard) => {}; }
| -------------- when calling this macro
5 | a!(if true);
| ----------- in this macro invocation
|
note: while trying to match meta-variable `$guard:guard`
--> src/lib.rs:4:19
|
4 | macro_rules! b { ($guard:guard) => {}; }
| ^^^^^^^^^^^^
= note: this error originates in the macro `a` (in Nightly builds, run with -Z macro-backtrace for more info)
```
---
While I'm still skeptical of `guard` fragment specifiers in general (although I can't quite pinpoint why), I figured I should fix this issue.
add regression test for OpenOptionsExt downstream compat
Following up on rust-lang/rust#153491, which added a warning comment there, but no automated guardrail to prevent another breaking change like rust-lang/rust#149718
This adds a simple windows-only ui test that manually implements `OpenOptionsExt`. That way, if someone accidentally adds another required method to the trait, we catch it before it reaches stable and breaks downstream crates like Tokio again.
Closesrust-lang/rust#153486
cg_llvm: scalable vectors with `simd_cast` and `simd_select`
Previously `sve_cast`'s implementation was abstracted to power both `sve_cast` and `simd_cast` which supported scalable and non-scalable vectors respectively. In anticipation of having to do this for another `simd_*` intrinsic, `sve_cast` is removed and `simd_cast` is changed to accept both scalable and non-scalable intrinsics, an approach that will scale better to the other intrinsics.
Building on the previous change, support scalable vectors with `simd_select`. Previous patches already landed the necessary changes in the implementation of this intrinsic, but didn't allow scalable vector arguments to be passed in.
Daniel Scherzer