Constify remaining traits/impls for const_ops by clarfonthey · Pull Request #143949 · rust-lang/rust (original) (raw)
Tracking issue: #143802
This is split into two commits for ease of reviewability:
- Updates the
forward_ref_*macros to accept multiple attributes (in anticipation of needingrust_const_unstableattributes) and also require attributes in these macros. Since the default attribute only helps for the initial implementations, it means it's easy to get wrong for future implementations, as shown for the saturating implementations which were incorrect before. - Actually constify the traits/impls.
A few random other notes on the implementation specifically:
- I unindented the attributes that were passed to the
forward_ref_*macro calls because in some places rustfmt wanted them to be unindented, and in others it was allowed because they were themselves inside of macro bodies. I chose the consistent indenting even though I (personally) think it looks worse.
As far as the actual changes go, this constifies the following additional traits:
NegNotBitAndBitOrBitXorShlShrAddAssignSubAssignMulAssignDivAssignRemAssignBitAndAssignBitOrAssignBitXorAssignShlAssignShrAssign
In terms of constified implementations of these traits, it adds the reference-forwarded versions of all the arithmetic operators, which are defined by the macros in library/core/src/internal_macros.rs. I'm not going to fully enumerate these because we'd be here all day, but sufficed to say, it effectively allows adding an & to one or both sides of an operator for primitives.
Additionally, I constified the implementations for Wrapping, Saturating, and NonZero as well, since all of them forward to already-const-stable methods. (potentially via intrinsics, to avoid extra overhead)
There are three "non-primitive" types which implement these traits, listed below. Note that I put "non-primitive" in quotes since I'm including Wrapping, Saturating, and NonZero, which are just wrappers over primitives.
Duration(arithmetic operations)SystemTime(arithmetic operations)Ipv4Addr(bit operations)Ipv6Addr(bit operations)
Additionally, because the methods on SystemTime needed to make these operations const were not marked const, a separate tracking issue for const-stabilising those methods is #144517.
Stuff left out of this PR:
Assume(this could trivially be made const, but since the docs indicate this is still under heavy design, I figured I'd leave it out)Instant(this could be made const, but cannot reasonably be constructed at constant time, so, isn't useful)SystemTime(will submit separate PR)- SIMD types (I'm tackling these all at once later; see Constified SIMD portable-simd#467)