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
Update compiler/rustc_monomorphize/src/collector.rs
Add FIXME(mgca) comment to potentially re-investigate in the future.
Co-Authored-By: Boxy <rust@boxyuwu.dev>
This fully rewords the diagnostic that was previously only emitted for assoc ty bindings.
That's because it incorrectly called trait aliases *type aliases* and didn't really
make it clear what the root cause is.
The added test used to ICE prior to this change.
I've double-checked that the preexisting test I've modified still ICEs in
nightly-2025-03-29.
We used to lower such bad defaulted const args in trait object types to
`{type error}`; now correctly lower them to `{const error}`.
The added tests used to ICE prior to this change.
