Different trade-offs for or_fun_call false positives #12724
Description
Description
I'm seeing the or_fun_call lint complain about use of methods that are cheap (e.g. vec.first(), x.as_ref().and_then(…), x.unwrap_or("str"), "".as_ref(), x.unwrap_or(Path::new(""))).
I've searched previous discussions about this lint, and it seems that various heuristics for detecting cheap methods were rejected, because sometimes there are edge cases that might be expensive.
Could there be another lint, or a setting for this lint, that changes the policy from warning just in case to warning only about methods that are actually known to have non-trivial cost? (prefer false negatives over false positives)
Version
rustc 1.79.0-nightly (3a36386dc 2024-04-25)
binary: rustc
commit-hash: 3a36386dc1075018dc7ca2640a2656adb31a61fe
commit-date: 2024-04-25
host: aarch64-apple-darwin
release: 1.79.0-nightly
LLVM version: 18.1.4
Additional Labels
No response