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