arithmetic_side_effects doesn't fire in non-const function located inside of const definition

[u59149403]

Summary

arithmetic_side_effects doesn't fire in non-const function located inside of const definition. (See below for why it is important for me.)

Lint Name

arithmetic_side_effects

Reproducer

I tried this code:

// Add alloy 0.8.1 as a dependency

#![deny(clippy::arithmetic_side_effects)]

const _: () = {
    fn f() {
        let _ = alloy::primitives::U256::from(1) + alloy::primitives::U256::from(2);
    }
};

I expected to see this happen: arithmetic_side_effects should fire.

Instead, this happened: nothing fired.

Note: it is documented that arithmetic_side_effects will not fire in const contexts. But this is not const context.

Okay, now let me describe, why this is important and how this actually breaks my workflow.

Okay, so I use crate alloy for managing my money. alloy provides type U256 for dealing with monetary values. U256 is borrowed from another crate ruint. I don't want silent overflows, I want panics on overflow, so I filled bug to ruint, hoping they will add panics-on-overflow: recmo/uint#408 . But a developer said that they don't want to change the behavior, so I have to resort to some hacks on my side. So I decided to use clippy's lint arithmetic_side_effects to eliminate arithmetic operations with U256 in my code and use checked_add and similar instead.

But I'm not sure that arithmetic_side_effects will always work. It is possible that it will change its behavior in some next version of clippy. Notably, arithmetic_side_effects currently doesn't fire on Wrapping. It is possible that following same logic authors of clippy will disable this lint for U256, too, because U256 has wrapping behavior, too! So, I need some way to be sure that arithmetic_side_effects will always fire in the future. So, I decided to use #[expect].

So, I put this function to my code:

#![deny(clippy::arithmetic_side_effects)]

// ...

fn f() {
  #[expect(clippy::arithmetic_side_effects)]
  {
    let _ = alloy::primitives::U256::from(1) + alloy::primitives::U256::from(2);
  }
}

Okay, this works, but has some problems. First, f is not used, so it fires warning about dead code. Second, I need to invent new name for every such function, despite I don't plan to call them. And finally, such functions pollute global name space.

It is possible to put this function to some module, but then the problem reappears again, because now I have to invent some name for this module, despite I don't plan to use it.

So, I decided to use const _: () trick:

#![deny(clippy::arithmetic_side_effects)]

#[expect(clippy::arithmetic_side_effects)]
const _: () = { alloy::primitives::U256::from(1) + alloy::primitives::U256::from(2); };

But this is const context. And arithmetic_side_effects is documented not to fire in the const contexts. Moreover, this code doesn't even compile. So, I did this:

#![deny(clippy::arithmetic_side_effects)]

const _: () = {
    fn f() {
        #[expect(clippy::arithmetic_side_effects)]
        {
            let _ = alloy::primitives::U256::from(1) + alloy::primitives::U256::from(2);
        }
    }
};

Unfortunately, this code gives message this lint expectation is unfulfilled. It seems this non-const context is treated as const by clippy. This is a bug, and thus I reported it

Version

rustc 1.85.0-nightly (a224f3807 2024-12-09)
binary: rustc
commit-hash: a224f3807e58afc9353510f1d556c607d367545d
commit-date: 2024-12-09
host: x86_64-unknown-linux-gnu
release: 1.85.0-nightly
LLVM version: 19.1.5

[c410-f3r]

This issue probably isn't related to the lint.

• It is not possible to call a non-const function is a const environment.
• It is not currently possible to call trait methods (From::from) in const environments.
• The provided snippet is compiling because of dead-code elimination.

Here goes a snippet that panics when an overflow occurs.

use ruint::Uint;

// For example, an overflow will trigger if you change [0; 32] to [255; 32]
const _: () = {
  const fn f() {
    let _: Uint<256, 4> = Uint::from_be_bytes([0; 32]).checked_add(Uint::from_be_bytes([0; 32])).unwrap();
  }
  f()
};

[u59149403]

It is not possible to call a non-const function is a const environment.

Yes. But still this bug allows me to perform non-const addition, which will be missed by the lint. Okay, here is another example:

#![deny(clippy::arithmetic_side_effects)]

const G: fn () = {
    fn f() {
        let _ = alloy::primitives::U256::from(1) + alloy::primitives::U256::from(2);
    }
    f
};

fn main() {
    G();
}

This code will actually perform real non-const addition in runtime. This is exactly thing that this lint supposed to catch. But the lint will not fire. This is totally real false negative.

The provided snippet is compiling because of dead-code elimination.

The new code I gave above doesn't have dead code.

Here goes a snippet that panics when an overflow occurs.

Yes. So what? Let me describe again what I need. First of all, I need overflow detection when I deal with U256. I know I can achieve this using checked_add. Also I want to be sure that I never occasionally use simple + instead of checked_add. So I use clippy::arithmetic_side_effects lint. But also I want to be sure that this lint will work with future versions of clippy, i. e. I want to be sure that this lint will not change semantics in future versions of clippy. So I added that #[expect] code to my real production code base. #[expect] is feature, which is designed for exactly this use case, i. e. to make sure that compiler's and clippy's lint will behave as expected in future versions of compiler or clippy. You can learn more about #[expect] here: rust-lang/rfcs#2383 . But, because of this bug (i. e. bug #13845 ) this will not work. I explained all this in the first message.

So, again: don't show me examples of code showing how to catch overflows. I already know how to catch overflows. I added to my production code base that #[expect] code not to catch overflows (I already catch them thanks to checked_add and clippy::arithmetic_side_effects), but to catch possible semantics change of clippy::arithmetic_side_effects in future versions of clippy