Ignore const fn in or_fun_call lint

[tesuji]

cc #1609 (comment)
Closes #5658

changelog: none

[oli-obk]

I don't think the constness of the function by itself will give us what we want. If the function is a const fn, but has arguments, these arguments may not be constants. An example:

const fn compute_nth_prime(n: usize) -> Option<usize> {
    // super heavy logic here
}
fn foo(n: usize) -> Option<usize> {
	// Whether the function above is `const fn` or not has no effect on the cost
    // of the work done in the `or`.
	None.or(compute_nth_prime(n))
}

Thus, we'll end up actually running the function at runtime, with all the runtime effort that comes with it. If you really want to do this, you'll need to analyze the entire expression and check if it is entirely const.

I don't know of a reliable way to do this except to do it on MIR, which would be a major undertaking.

[matthiaskrgr]

This is a user-facing change, the "changelog:" line should say which false positive this fixes.

[tesuji]

cc @ecstatic-morse do you know how to detect if a const fn could be evaluated at compile-time.

[oli-obk]

This is not about whether it could be evaluated at compile-time. A const fn by definition can be evaluated at compile-time. It's whether your expression can be evaluated at compile time. I think the cleanest way would be to implement const fn const prop in rustc and make this lint a MIR lint that just checks whether the argument to or is a const (or one of the whitelisted kinds of functions here).

[bors]

☔ The latest upstream changes (presumably #5691) made this pull request unmergeable. Please resolve the merge conflicts.

[tesuji]

I don't think I have enough skills to make that change.
Closing this PR in the mean time.