Fast reject for NeedsNonConstDrop
Hopefully fixes the regression in #88558.
I've always wanted to help with the performance of rustc, but it doesn't feel the same when you are fixing a regression caused by your own PR...
r? `@oli-obk`
Allow `panic!("{}", computed_str)` in const fn.
Special-case `panic!("{}", arg)` and translate it to `panic_display(&arg)`. `panic_display` will behave like `panic_any` in cosnt eval and behave like `panic!(format_args!("{}", arg))` in runtime.
This should bring Rust 2015 and 2021 to feature parity in terms of `const_panic`; and hopefully would unblock the stabilisation of #51999.
`@rustbot` modify labels: +T-compiler +T-libs +A-const-eval +A-const-fn
r? `@oli-obk`
Highlight the `const fn` if error happened because of a bound on the impl block
Currently, for the following code, the compiler produces the errors like the
following:
```rust
struct Type<T>(T);
impl<T: Clone> Type<T> {
const fn f() {}
}
```
```text
error[E0658]: trait bounds other than `Sized` on const fn parameters are unstable
--> ./test.rs:3:6
|
3 | impl<T: Clone> Type<T> {
| ^
|
= note: see issue #57563 <https://github.com/rust-lang/rust/issues/57563> for more information
= help: add `#![feature(const_fn_trait_bound)]` to the crate attributes to enable
```
This can be confusing (especially to newcomers) since the error mentions "const fn parameters", but highlights only the impl.
This PR adds function highlighting, changing the error to the following:
```text
error[E0658]: trait bounds other than `Sized` on const fn parameters are unstable
--> ./test.rs:3:6
|
3 | impl<T: Clone> Type<T> {
| ^
4 | pub const fn f() {}
| ---------------- function declared as const here
|
= note: see issue #57563 <https://github.com/rust-lang/rust/issues/57563> for more information
= help: add `#![feature(const_fn_trait_bound)]` to the crate attributes to enable
```
---
I've originally wanted to point directly to `const` token, but couldn't find a way to get it's span. It seems like this span is lost during the AST -> HIR lowering.
Also, since the errors for object casts in `const fn`s (`&T` -> `&dyn Trait`) seem to trigger the same error, this PR accidentally changes these errors too. Not sure if it's desired or how to fix this.
P.S. it's my first time contributing to diagnostics, so feedback is very appreciated!
---
r? ```@estebank```
```@rustbot``` label: +A-diagnostics
Const drop
The changes are pretty primitive at this point. But at least it works. ^-^
Problems with the current change that I can think of now:
- [x] `~const Drop` shouldn't change anything in the non-const world.
- [x] types that do not have drop glues shouldn't fail to satisfy `~const Drop` in const contexts. `struct S { a: u8, b: u16 }` This might not fail for `needs_non_const_drop`, but it will fail in `rustc_trait_selection`.
- [x] The current change accepts types that have `const Drop` impls but have non-const `Drop` glue.
Fixes#88424.
Significant Changes:
- `~const Drop` is no longer treated as a normal trait bound. In non-const contexts, this bound has no effect, but in const contexts, this restricts the input type and all of its transitive fields to either a) have a `const Drop` impl or b) can be trivially dropped (i.e. no drop glue)
- `T: ~const Drop` will not be linted like `T: Drop`.
- Instead of recursing and iterating through the type in `rustc_mir::transform::check_consts`, we use the trait system to special case `~const Drop`. See [`rustc_trait_selection::...::candidate_assembly#assemble_const_drop_candidates`](https://github.com/fee1-dead/rust/blob/const-drop/compiler/rustc_trait_selection/src/traits/select/candidate_assembly.rs#L817) and others.
Changes not related to `const Drop`ping and/or changes that are insignificant:
- `Node.constness_for_typeck` no longer returns `hir::Constness::Const` for type aliases in traits. This was previously used to hack how we determine default bound constness for items. But because we now use an explicit opt-in, it is no longer needed.
- Removed `is_const_impl_raw` query. We have `impl_constness`, and the only existing use of that query uses `HirId`, which means we can just operate it with hir.
- `ty::Destructor` now has a field `constness`, which represents the constness of the destructor.
r? `@oli-obk`
Currently, for the following code, the compiler produces the errors like the
following error:
```rust
struct Type<T>
impl<T: Clone> Type<T> {
fn const f() {}
}
```
```text
error[E0658]: trait bounds other than `Sized` on const fn parameters are unstable
--> ./test.rs:3:6
|
3 | impl<T: Clone> Type<T> {
| ^
|
= note: see issue #57563 <https://github.com/rust-lang/rust/issues/57563> for more information
= help: add `#![feature(const_fn_trait_bound)]` to the crate attributes to enable
```
This can be confusing (especially to newcomers) since the error mentions
"const fn parameters", but highlights only the impl.
This commits adds function highlighting, changing the error to the following:
```text
error[E0658]: trait bounds other than `Sized` on const fn parameters are unstable
--> ./test.rs:3:6
|
3 | impl<T: Clone> Type<T> {
| ^
4 | pub const fn f() {}
| ---------------- function declared as const here
|
= note: see issue #57563 <https://github.com/rust-lang/rust/issues/57563> for more information
= help: add `#![feature(const_fn_trait_bound)]` to the crate attributes to enable
```
Introduce NullOp::AlignOf
This PR introduces `Rvalue::NullaryOp(NullOp::AlignOf, ty)`, which will be lowered from `align_of`, similar to `size_of` lowering to `Rvalue::NullaryOp(NullOp::SizeOf, ty)`.
The changes are originally part of #88700 but since it's not dependent on other changes and could have performance impact on its own, it's separated into its own PR.
Move *_max methods back to util
change to inline instead of inline(always)
Remove valid_range_exclusive from scalar
Use WrappingRange instead
implement always_valid_for in a safer way
Fix accidental edit
