rust/compiler/rustc_hir
Jubilee 3313e760d0
Rollup merge of #132423 - RalfJung:const-eval-align-offset, r=dtolnay
remove const-support for align_offset and is_aligned

As part of the recent discussion to stabilize `ptr.is_null()` in const context, the general vibe was that it's okay for a const function to panic when the same operation would work at runtime (that's just a case of "dynamically detecting that something is not supported as a const operation"), but it is *not* okay for a const function to just return a different result.

Following that, `is_aligned` and `is_aligned_to` have their const status revoked in this PR, since they do return actively wrong results at const time. In the future we can consider having a new intrinsic or so that can check whether a pointer is "guaranteed to be aligned", but the current implementation based on `align_offset` does not have the behavior we want.

In fact `align_offset` itself behaves quite strangely in const, and that support needs a bunch of special hacks. That doesn't seem worth it. Instead, the users that can fall back to a different implementation should just use const_eval_select directly, and everything else should not be made const-callable. So this PR does exactly that, and entirely removes const support for align_offset.

Closes some tracking issues by removing the associated features:
Closes https://github.com/rust-lang/rust/issues/90962
Closes https://github.com/rust-lang/rust/issues/104203

Cc `@rust-lang/wg-const-eval` `@rust-lang/libs-api`
2024-11-03 20:08:13 -08:00
..
src Rollup merge of #132423 - RalfJung:const-eval-align-offset, r=dtolnay 2024-11-03 20:08:13 -08:00
Cargo.toml compiler: Replace rustc_target with _abi in _hir 2024-11-02 20:31:47 -07:00