Clean up or resolve cfg-related instances of `FIXME(f16_f128)`
* Replace target-specific config that has a `FIXME` with `cfg(target_has_reliable_f*)`
* Take care of trivial intrinsic-related FIXMEs
* Split `FIXME(f16_f128)` into `FIXME(f16)`, `FIXME(f128)`, or `FIXME(f16,f128)` to more clearly identify what they block
The individual commit messages have more details.
Add -Z large-data-threshold
This flag allows specifying the threshold size for placing static data in large data sections when using the medium code model on x86-64.
When using -Ccode-model=medium, data smaller than this threshold uses RIP-relative addressing (32-bit offsets), while larger data uses absolute 64-bit addressing. This allows the compiler to generate more efficient code for smaller data while still supporting data larger than 2GB.
This mirrors the -mlarge-data-threshold flag available in GCC and Clang. The default threshold is 65536 bytes (64KB) if not specified, matching LLVM's default behavior.
There are a number of instances of `FIXME(f16_f128)` related to target
configuration; either these could use `target_has_reliable_f128`, or the
FIXME is describing such a cfg and is thus redundant (since any
`cfg(target_has_reliable_f*)` needs to be removed before stabilization
anyway).
Switch to using `target_has_reliable_*` where applicable and remove the
redundant FIXMEs.
Fix ICE when using zero-length SIMD type in extern static
before my fix using a zero-length SIMD type in an extern static would cause an internal compiler error. now it properly shows a diagnostic error instead of panicking. it was because `LayoutError::InvalidSimd` wasn't handled in `check_static_inhabited` and fell through to a generic `delayed_bug`.
i added handling for `InvalidSimd` in `check_static_inhabited` (similar to `SizeOverflow`): when a SIMD type has an invalid layout, we call `emit_err` with `Spanned` to emit a normal error instead of an ICE. compiler now emits a clear error `"the SIMD type Simd<u8, 0> has zero elements"` with the correct span on the type, matching expected compiler behavior.
fixesrust-lang/rust#151451
Previously, using a zero-length SIMD type in an extern static would
cause an internal compiler error. Now it properly emits a diagnostic
error instead of panicking.
Avoid `-> ()` in derived functions.
`hash` and `assert_receiver_is_total_eq` have no return type. This commit removes the `-> ()` that is currently printed for them.
r? @Kobzol
llvm: Tolerate dead_on_return attribute changes
The attribute now has a size parameter and sorts differently. Adjust tests to tolerate this.
https://github.com/llvm/llvm-project/pull/171712
r? durin42
@rustbot label llvm-main
Fix ICE: Don't try to evaluate type_consts when eagerly collecting items
This fixes https://github.com/rust-lang/rust/issues/151246
The change is pretty straightforward if the Monomorphization strategy is eager which `-Clink-dead-code=true` sets. This then would lead to the existing code to try and evaluate a `type const` which does not have a body to evaluate leading to an ICE. The change is pretty straight forward just skip over type consts.
This also seems like a sensible choice to me since a MonoItem can only be a Fn, Static, or Asm. A type const is none of the aforementioned.
And even if it was added to the MonoItems list it would then later fail this check:
fe98ddcfcf/compiler/rustc_monomorphize/src/collector.rs (L438-L440)
Since that explicitly checks that the MonoItem's `DefKind` is static and not anything else.
One more change is the addition of a simple test of the example code from https://github.com/rust-lang/rust/issues/151246 that checks that code compiles successfully with `-Clink-dead-code=true`.
The only other change was to make the guard checks a little easier to read by making the logic more linear instead of one big if statement.
r? @BoxyUwU
@rustbot label +F-associated_const_equality +F-min_generic_const_args
MGCA: Fix incorrect pretty printing of valtree arrays
Fixesrust-lang/rust#151126
- **add failing test**
- **fix: additional check whether const array could be printed as raw bytes**
As I figured out, the problem was in `pretty_print_const_valtree`, where it tried to print unevaluated consts as if they were evaluated, which resulted in ICE.
Handle unevaluated ConstKind in in_operand
fix: rust-lang/rust#151248
r? BoxyUwU
~~I can't reproduce rust-lang/rust#151246 in my local(x86_64-pc-windows-msvc) even before this change. 🤔
create a draft and test it in different environments.~~
rustdoc: render doc(hidden) as a code attribute
Move `#[doc(hidden)]` into the shared code-attribute renderer so it matches the styling and placement of other attributes in rustdoc HTML.
Closesrust-lang/rust#132304
Improve error message for assert!() macro in functions returning bool
Detect `assert!()` macro in error messages and provide clearer diagnostics
When `assert!()` is used in a function returning a value, show a message explaining that `assert!()` doesn't return a value, instead of the generic "if may be missing an else clause" error.
Fixesrust-lang/rust#151446
Port `#![crate_type]` to the attribute parser
Tracking issue: https://github.com/rust-lang/rust/issues/131229
~~Note that the actual parsing that is used in the compiler session is unchanged, as it must happen very early on; this just ports the validation logic.~~
Also added `// tidy-alphabetical-start` to `check_attr.rs` to make it a bit less conflict-prone
Support slices in type reflection
Tracking issue: rust-lang/rust#146922
This PR adds support for inspecting slices `[T]` through type reflection. It does so by adding the new `Slice` struct + variant, which is very similar to `Array` but without the `len` field:
```rust
pub struct Slice {
pub element_ty: TypeId,
}
```
Here is an example reflecting a slice:
```rust
match const { Type::of::<[u8]>() }.kind {
TypeKind::Slice(slice) => assert_eq!(slice.element_ty, TypeId::of::<u8>()),
_ => unreachable!(),
}
```
In addition to this, I also re-arranged the type info unit tests.
r? @oli-obk
mGCA: Make trait object types with type-level associated consts dyn compatible
Under feature `min_generic_const_args` (mGCA) (rust-lang/rust#132980), render traits with non-parametrized type-level associated constants (i.e., `#[type_const]` ones) dyn compatible but force the user to specify all type-level associated consts in the trait object type via bindings (either directly, via supertrait bounds and/or behind trait aliases) just like associated types, their sibling.
Fixesrust-lang/rust#130300 (feature request).
Fixesrust-lang/rust#136063 (bug).
Fixesrust-lang/rust#137260 (bug).
Fixesrust-lang/rust#137514 (bug).
While I'm accounting for most illegal `Self` references via const projections & params, I'm intentionally ignoring RUST-123140 (and duplicates) in this PR which is to be tackled some other time.
Additional context: Crate `rustc-demangle` had to be updated to fix v0 demangling. I've patched it in PR https://github.com/rust-lang/rustc-demangle/pull/87 which was was released in version 0.1.27 via PR https://github.com/rust-lang/rustc-demangle/pull/88.
The attribute now has a size parameter and sorts differently:
* Explicitly omit size parameter during construction on 23+
* Tolerate alternate sorting in tests
https://github.com/llvm/llvm-project/pull/171712
Port some crate level attrs to the attribute parser
Tracking issue: https://github.com/rust-lang/rust/issues/131229
Ports compiler_builtins, panic_runtime, needs_panic_runtime, profiler_runtime and no_builtins to the attribute parsing infrastructure.
r? @JonathanBrouwer
Fixed ICE when using function pointer as const generic parameter
added bounds check in prohibit_explicit_late_bound_lifetimes to prevent index out of bounds panic when args.args is empty. also regression test here to ensure function pointers in const generics produce proper error messages instead of ICE.
Fixesrust-lang/rust#151186Fixesrust-lang/rust#137084
make `simd_insert_dyn` and `simd_extract_dyn` const
For use in `stdarch`. We currently use an equivalent of the fallback body here, but on some targets the intrinsic generate better code.
r? RalfJung
