Refactor FnDecl and FnSig non-type fields into a new wrapper type
#### Why this Refactor?
This PR is part of an initial cleanup for the [arg splat experiment](https://github.com/rust-lang/rust/issues/153629), but it's a useful refactor by itself.
It refactors the non-type fields of `FnDecl`, `FnSig`, and `FnHeader` into a new packed wrapper types, based on this comment in the `splat` experiment PR:
https://github.com/rust-lang/rust/pull/153697#discussion_r3004637413
It also refactors some common `FnSig` creation settings into their own methods. I did this instead of creating a struct with defaults.
#### Relationship to `splat` Experiment
I don't think we can use functional struct updates (`..default()`) to create `FnDecl` and `FnSig`, because we need the bit-packing for the `splat` experiment.
Bit-packing will avoid breaking "type is small" assertions for commonly used types when `splat` is added.
This PR packs these types:
- ExternAbi: enum + `unwind` variants (38) -> 6 bits
- ImplicitSelfKind: enum variants (5) -> 3 bits
- lifetime_elision_allowed, safety, c_variadic: bool -> 1 bit
#### Minor Changes
Fixes some typos, and applies rustfmt to clippy files that got skipped somehow.
Most diagnostic types are only used within their own crate, and so have
a `pub(crate)` visibility. We have some diagnostic types that are
unnecessarily `pub`. This is bad because (a) information hiding, and (b)
if a `pub(crate)` type becomes unused the compiler will warn but it
won't warn for a `pub` type.
This commit eliminates unnecessary `pub` visibilities for some
diagnostic types, and also some related things due to knock-on effects.
(I found these types with some ad hoc use of `grep`.)
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
`ty::Alias` refactor
This PR changes the following alias-related types from this:
```rust
pub enum AliasTyKind {
Projection,
Inherent,
Opaque,
Free,
}
pub struct AliasTy<I: Interner> {
pub args: I::GenericArgs,
pub def_id: I::DefId,
}
pub enum TyKind<I: Interner> {
...
Alias(AliasTyKind, AliasTy<I>),
}
```
Into this:
```rust
pub enum AliasTyKind<I: Interner> {
Projection { def_id: I::DefId },
Inherent { def_id: I::DefId },
Opaque { def_id: I::DefId },
Free { def_id: I::DefId },
}
pub struct AliasTy<I: Interner> {
pub args: I::GenericArgs,
pub kind: AliasTyKind<I>,
}
pub enum TyKind<I: Interner> {
...
Alias(AliasTy<I>),
}
```
... and then does a thousand other changes to accommodate for this change everywhere.
This brings us closer to being able to have `AliasTyKind`s which don't require a `DefId` (and thus can be more easily created, etc). Although notably we depend on both `AliasTyKind -> DefId` and `DefId -> AliasTyKind` conversions in a bunch of places still.
r? lcnr
----
A lot of these changes were done either by search & replace (via `ast-grep`) or on auto pilot, so I'm not quite sure I didn't mess up somewhere, but at least tests pass...
simd_fmin/fmax: make semantics and name consistent with scalar intrinsics
This is the SIMD version of https://github.com/rust-lang/rust/pull/153343: change the documented semantics of the SIMD float min/max intrinsics to that of the scalar intrinsics, and also make the name consistent. The overall semantic change this amounts to is that we restrict the non-determinism: the old semantics effectively mean "when one input is an SNaN, the result non-deterministically is a NaN or the other input"; the new semantics say that in this case the other input must be returned. For all other cases, old and new semantics are equivalent. This means all users of these intrinsics that were correct with the old semantics are still correct: the overall set of possible behaviors has become smaller, no new possible behaviors are being added.
In terms of providers of this API:
- Miri, GCC, and cranelift already implement the new semantics, so no changes are needed.
- LLVM is adjusted to use `minimumnum nsz` instead of `minnum`, thus giving us the new semantics.
In terms of consumers of this API:
- Portable SIMD almost certainly wants to match the scalar behavior, so this is strictly a bugfix here.
- Stdarch mostly stopped using the intrinsic, except on nvptx, where arguably the new semantics are closer to what we actually want than the old semantics (https://github.com/rust-lang/stdarch/issues/2056).
Q: Should there be an `f` in the intrinsic name to indicate that it is for floats? E.g., `simd_fminimum_number_nsz`?
Also see https://github.com/rust-lang/rust/issues/153395.
Merge `fabsf16/32/64/128` into `fabs::<F>`
Following [a small conversation on Zulip](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Float.20intrinsics/with/521501401) (and because I'd be interested in starting to contribute on Rust), I thought I'd give a try at merging the float intrinsics :)
This PR just merges `fabsf16`, `fabsf32`, `fabsf64`, `fabsf128`, as it felt like an easy first target.
Notes:
- I'm opening the PR for one intrinsic as it's probably easier if the shift is done one intrinsic at a time, but let me know if you'd rather I do several at a time to reduce the number of PRs.
- Currently this PR increases LOCs, despite being an attempt at simplifying the intrinsics/compilers. I believe this increase is a one time thing as I had to define new functions and move some things around, and hopefully future PRs/commits will reduce overall LoCs
- `fabsf32` and `fabsf64` are `#[rustc_intrinsic_const_stable_indirect]`, while `fabsf16` and `fabsf128` aren't; because `f32`/`f64` expect the function to be const, the generic version must be made indirectly stable too. We'd need to check with T-lang this change is ok; the only other intrinsics where there is such a mismatch is `minnum`, `maxnum` and `copysign`.
- I haven't touched libm because I'm not familiar with how it works; any guidance would be welcome!
interpreter error reporting: remove arguments that are always the same
This `report` function is called twice and both callers use the same `span` and `get_span_and_frames`... so let's just fix those arguments inside the function, no need to be more generic than this.
miri recursive validation: only check one layer deep
As has been proposed in https://github.com/rust-lang/unsafe-code-guidelines/issues/414, let's see what happens if we make recursive checking in Miri shallow: we treat whatever is behind a reference as if it was inside `MaybeDangling`, which means nested references do not have to be dereferenceable.
This changes the meaning of the original flag -- I don't think it is worth supporting multiple variants of recursive checking (it'd require a bunch of new plumbing), and this seems to be the strictest variant that still has any traction in the discussion.
interpret: when passing an argument fails, point at that argument
For a long time now, we did some contortions so that when something goes wrong while initializing the arguments for a function, we point at the call site rather than the callee. Historically, this had to be done because the "current location" in the callee pointed at the first instruction, which would obviously be nonsense. A while ago we gained the ability in the interpreter for the "current location" to be just a span that we point at for errors, but we never reevaluated the decision for how spans are handled during function calls. (We did use this "just a span" location for [errors during the initial stack frame setup](https://github.com/rust-lang/rust/commit/d21e0118d0eefc8b0073fa47fa16699d37047abf), but not for argument initialization.)
There's no always-great choice for pointing at the caller vs the callee: when they disagree about the type of an argument, either side could be wrong. If We do *two* typed copies in that case, one at the caller type and one at the callee type. Arguably we should point at the one that goes wrong, but we don't have a good way to expose that.
What ultimately pushed me over the edge towards pointing at the callee are two points:
- This provides strictly more information. if we point at the callee, the caller is available in the stacktrace. But if we point at the caller, then it might be impossible to figure out the actual callee if a function pointer or dyn call is involved.
- As part of resolving some long-standing questions around retags I am moving retagging to become part of validation, which means the retag and protector initialization of function arguments will happen during argument initialization. These currently point at the argument inside the callee, which I think is strictly preferable for these errors.
The diff will be much smaller with whitespace changes hidden.
const validity checking: do not recurse to references inside MaybeDangling
This arguably should be allowed, but we currently reject it:
```rust
#![feature(maybe_dangling)]
use std::mem::MaybeDangling;
const X: MaybeDangling<&bool> = unsafe { std::mem::transmute(&5u8) };
```
r? @WaffleLapkin
Simplify find_attr! for HirId usage
Add a `HasAttrs<'tcx, Tcx>` trait to `rustc_hir` that allows `find_attr!` to accept `DefId`, `LocalDefId`, `OwnerId`, and `HirId` directly, instead of requiring callers to manually fetch the attribute slice first.
Before:
`find_attr!(tcx.hir_attrs(hir_id), SomeAttr)`
After:
`find_attr!(tcx, hir_id, SomeAttr)`
The trait is defined in `rustc_hir` with a generic `Tcx` parameter to avoid a dependency cycle (`rustc_hir` cannot depend on `rustc_middle`). The four concrete impls for `TyCtxt` are in `rustc_middle`.
Fixes https://github.com/rust-lang/rust/issues/153103
Add a HasAttrs<'tcx, Tcx> trait to rustc_hir that allows find_attr! to
accept DefId, LocalDefId, OwnerId, and HirId directly, instead of
requiring callers to manually fetch the attribute slice first.
The trait is defined in rustc_hir with a generic Tcx parameter to avoid
a dependency cycle (rustc_hir cannot depend on rustc_middle). The four
concrete impls for TyCtxt are in rustc_middle.
interpret: go back to regular string interpolation for error messages
Using the translatable diagnostic infrastructure adds a whole lot of boilerplate which isn't actually useful for const-eval errors, so let's get rid of it. This effectively reverts https://github.com/rust-lang/rust/pull/111677. That PR effectively added 1000 lines and this PR only removes around 600 -- the difference is caused by (a) keeping some of the types around for validation, where we can use them to share error strings and to trigger the extra help for pointer byte shenanigans during CTFE, and (b) this not being a full revert of rust-lang/rust#111677; I am not touching diagnostics outside the interpreter such as all the const-checking code which also got converted to fluent in the same PR.
The last commit does something similar for `LayoutError`, which also helps deduplicate a bunch of error strings. I can make that into a separate PR if you prefer.
r? @oli-obk
Fixes https://github.com/rust-lang/rust/issues/113117
Fixes https://github.com/rust-lang/rust/issues/116764
Fixes https://github.com/rust-lang/rust/issues/112618
miri: make read_discriminant UB when the tag is not in the validity range of the tag field
Arguably, reading an enum discriminant is an operation that uses the "type" of the discriminant field -- and therefore it should fail when the value in that field isn't valid at that type. Therefore, code like this should be UB:
```rust
fn main() {
unsafe {
let x = 12u8;
let x_ptr: *const u8 = &x;
let cast_ptr = x_ptr as *const Option<bool>;
// Reading the discriminant should fail since the tag value is not in the valid
// range for the tag field.
let _val = matches!(*cast_ptr, None);
//~^ ERROR: invalid tag
}
}
```
However, Miri currently sees no UB here. (MiniRust does see UB.) This is because we never actually check whether the tag we read is in the validity range for its field. So let's add such a check, and a corresponding test.
In fact, we have to do this check, since the codegen backend adds range metadata on the discriminant load, as can be seen in [this example](https://play.rust-lang.org/?version=stable&mode=release&edition=2024&gist=02ef5e80fdfe61540e44198dd827b630). In other words, the above code has UB in LLVM IR but not in Miri, which is a critical Miri bug.
Move `Spanned`.
It's defined in `rustc_span::source_map` which doesn't make any sense because it has nothing to do with source maps. This commit moves it to the crate root, a more sensible spot for something this basic.
r? @JonathanBrouwer
It's defined in `rustc_span::source_map` which doesn't make any sense
because it has nothing to do with source maps. This commit moves it to
the crate root, a more sensible spot for something this basic.
fix ICE in `const_c_variadic` when passing ZSTs
fixes https://github.com/rust-lang/rust/issues/153351
r? RalfJung
There was a mismatch between the caller and callee ABI where the caller does not pass ZST arguments, but the callee does expect them. Because ZSTs don't implement `VaArgSafe` the program must already be invalid if this comes up.
Oli Scherer