Constify remaining traits/impls for const_ops

[clarfonthey]

Tracking issue: #143802

This is split into two commits for ease of reviewability:

1. Updates the forward_ref_* macros to accept multiple attributes (in anticipation of needing rust_const_unstable attributes) 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.
2. 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:

• Neg
• Not
• BitAnd
• BitOr
• BitXor
• Shl
• Shr
• AddAssign
• SubAssign
• MulAssign
• DivAssign
• RemAssign
• BitAndAssign
• BitOrAssign
• BitXorAssign
• ShlAssign
• ShrAssign

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)
• Ipv4Addr (bit operations)
• Ipv6Addr (bit operations)

Note

Concerns (0 active)

• May break Clippy resolved in this comment

Managed by @rustbot—see help for details.

[rustbot]

r? @ibraheemdev

rustbot has assigned @ibraheemdev.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

[rustbot]

Only organization members can add or resolve concerns.

[samueltardieu]

@rustbot concern May break Clippy

(checking if concerns work as top-level comments only, real concern was written here, and discussion about the error message is on Zulip)

[samueltardieu]

@rustbot resolve May break Clippy

We cleared up the misunderstanding of what the problem was.

[clarfonthey]

Yeah, I'll be honest, I have genuinely no idea what those tests are doing. I could just add the feature flag, but it wasn't necessary before, and I don't know why.

[samueltardieu]

Yeah, I'll be honest, I have genuinely no idea what those tests are doing. I could just add the feature flag, but it wasn't necessary before, and I don't know why.

Didn't you just forget to replace #![feature(const_ops)] in library/coretests/tests/lib.rs?

[clarfonthey]

Didn't you just forget to replace #![feature(const_ops)] in library/coretests/tests/lib.rs?

Last time I checked this file, it didn't have it, but now it does. 🤷🏻

Literally tried rg const_ops in the library folder and got nothing last time, now it worked, so, issue fixed I guess.

[RalfJung]

TBH I think it'd be fine to have arith and bit ops in the same feature gate. We don't need a dozen of them, and it seems likely we'd stabilize these together.

[clarfonthey]

That's fair. I could combine the bit ops I've already gotten working into this PR, I just figured that it made more sense to separate them.

Part of my reason was to just simplify the review, but I guess that the compiler is used to 100-file changes, so… 🤷🏻

I also thought there would be more implementations to constify but for the arithmetic side it's just Duration as the odd one out, and for bit operations it's Ipv[46]Addr. So, not groundbreaking.

[clarfonthey]

Okay, I went for it and just incorporated the bit operations in this PR and undid the rename. After this, "all" of the operators are constified.

I say "all" because I'm excluding the Index and Deref operators, which deserve separate handling.

[blyxyas]

Wouldn't we want to check for tcx.features().const_ops()? (I'm not being able to find const_ops on Features)

[samueltardieu]

Have you seen the discussion starting at #143949 (comment)?

[clarfonthey]

Note, the proper fix should be done on the clippy repo later. The issue is that the bug is entirely unrelated to this change, but the changes make the existing test no longer pass, so, something has to give, and this was the minimal fix to at least get rid of some invalid suggestions.

[RalfJung]

const_ops is a library feature so tcx.features().const_ops() doesn't exist. tcx.features().enabled(...) should work though.

Cc @flip1995

[clarfonthey]

FWIW, there shouldn't be any feature checking here since both the assignment version of the operators and the non-assignment version are gated behind the same features, so, if you can use the non-assignment version, you will be able to use the assignment version.

The issue is that this isn't checking specifically for the bounds on both operators, since [const] Add doesn't guarantee [const] AddAssign. It does check that AddAssign is a bound when suggesting it, but it isn't also checking for [const] AddAssign when you're calling it in a const context.

[fee1-dead]

• we can't make the constness in the forward_ref_* macros work nicely without copy-pasting the macro body. Instead of doing that, I decided to go for a cursed extra const argument, which is then used for the actual const keyword. I explicitly mention named macro capture groups as a way of doing this better in the comments.

Are there impls covered by these macros that should not be marked const? Because I think if not we shouldn't even include a non-const case at all.

[clarfonthey]

That's a fair point; initially my thought process was that we would want to gradually do this, but grepping for forward_ref in the library directory shows that there's now only one usage left that isn't const. So, I'll do that instead.

I also missed the NonZero impls and will do those too. (I was checking for Add in my heuristic, but that only has Div, Rem, and Neg impls.)

[clarfonthey]

I only did x check for this so I'm hoping CI doesn't find anything I missed, but now every use of ref-forwarding is marked const. I also saw that stuff like IP addresses had manual implementations of ref-forwarding, but it didn't feel particularly necessary to update them to use the macro instead, at least for now.