`manual_clamp` misses when the upper bound is a function result

[JarredAllen]

Summary

manual_clamp doesn't trigger if one of the bounds being used is the return value from a function.

Applying this lint might change the meaning of the code if a function returns different results successive times it's called, but I think for a MaybeIncorrect lint it's reasonable to suggest this at least in cases where the function takes no mutable references and is given the same arguments.

Lint Name

manual_clamp

Reproducer

I tried this code:

fn upper_bound() -> f32 {
    5.0
}

pub fn manual_clamp(f: f32) -> f32 {
    if f < 0. { 0. } else if f > upper_bound() { upper_bound() } else { f }
}

I expected to see the manual_clamp lint trigger on the manual_clamp function.

Instead, this happened:

No lints

Version

rustc 1.94.0 (4a4ef493e 2026-03-02)
binary: rustc
commit-hash: 4a4ef493e3a1488c6e321570238084b38948f6db
commit-date: 2026-03-02
host: x86_64-unknown-linux-gnu
release: 1.94.0
LLVM version: 21.1.8

[paulmialane]

Hi, I was looking for an issue to contribute to and this one caught my attention.

I believe the issue is that function calls in clamp patterns are currently ignored because they may have side effects (applying the suggestion could result in different behavior). One approach could be to still lint these cases but inform the user that the suggestion may change behavior, though I'm not sure what the policy is for this kind of situation and wanted to discuss before going further. Would this be acceptable ?

If so, my question is: is there an idiomatic way in clippy to check if two expressions evaluate to the same value, including expressions that may have side effects (to replace the use of eq_expr_value that will fail on function calls)?

[paulmialane]

Actually, I looked into this again and the reason function calls are excluded is not just about side effects. There's a deeper safety concern. Even for functions with no mutable references, suggesting .clamp() is questionable because the suggested code will panic if min > max at runtime, whereas the original if/else chain never panics.

For example:

fn lower() -> f32 { 10.0 }
fn upper() -> f32 { 5.0 }

fn main() {
    let f = 7.0f32;
    // Original code, wrong result but no panic
    if f < lower() { lower() } else if f > upper() { upper() } else { f }

    // Suggested code, panic!
    let _ = f.clamp(lower(), upper());
}

The lint needs to check at compile time that lower() <= upper() and reject the suggestion if not. With function calls, I'm not sure it is possible to guaranty this at compile time.

This was discussed in #9484.

Happy to discuss further if you have ideas on how to work around this constraint.