or_fun_call triggers on const fn

[mahkoh]

const fn f(v: i32) -> Option<i32> {
    Some(v)
}

fn main() {
    None.or(f(1));  // try this: `or_else(|| f(1))`
}

[tesuji]

cc #1609

[ebroto]

Linking this relevant comment so that it does not get buried in a closed PR: #5682 (comment)

[tnielens]

Are const fn calls with const arguments guaranteed to be evaluated at compile-time?

From the unstable book I understand that they can be called in a const context, but nothing about evaluation guarantees.

[flip1995]

Are const fn calls with const arguments guaranteed to be evaluated at compile-time?

Good question. @oli-obk can you give some insights here?

[tesuji]

@montrivo No, it is only guaranteed to evaluate at compile time in const item or static item.

[tnielens]

@montrivo No, it is only guaranteed to evaluate at compile time in const item or static item.

If so, then I don't think clippy should handle const fns the way proposed in this issue's description, unless the const fn call is used in an expression assigned to a const variable.

Continuing on @oli-obk 's example:

const fn compute_nth_prime(n: usize) -> Option<usize> {
    // super heavy logic here
}

// here recommending `unwrap_or_else` is questionable since there is no runtime performance improvement 
// (although it might improve compilation time if `compute_nth_prime` is really heavy)
const a_prime_number: i32 = Some(13).unwrap_or(comput_nth_prime(42));

// here the lint is applicable, as unwrap_or will cause an unnecessary runtime cost 
// given compute_nth_prime(42) is not evaluated during compilation
fn main() {
  println!("{}", Some(42).unwrap_or(compute_nth_prime(42)));
}