`or_fun_call` isn't always a performance lint

[hrxi]

Replacing .unwrap_or(Vec::new()) with .unwrap_or_default() doesn't do anything for performance, they produce identical machine code with optimizations: https://rust.godbolt.org/z/hzTdazGqW.

Perhaps the lint category could be changed or it could be changed to not detect cases where it's not actually a performance warning?

[fedemartinezdev]

@rustbot claim

[fedemartinezdev]

Hi @hrxi !
I am new to contributing to rust-clippy.
Could you tell me where can I find the associated lint so I can begin to take a look? Thanks !

[xFrednet]

Hey @fedemartinezdev, welcome to Clippy 👋. In general we have Clippy's lint list which I use a lot. In this case, I searched for unwrap_or_default and found or_fun_call which is the mentioned lint. This issue requires some detective work to see if any of the cases are still better performance wise or if the entire lint group should be changed. For that, you might have to look at the implementation, to see how the lint internally works 🙃 See clippy_lints/src/methods/or_fun_call.rs

[nikomatsakis]

I ran into this same issue! It's not just Vec::new, I think the same would be true of HashMap::new and other standard library collections.

[hrxi]

I just ran into more clippy suggestions where it doesn't improve performance:

String::from_utf8(vec).or(Err(Enum::InvalidUtf8))

Or a couple of others, the pattern is the same, .or(EnumVariant(PlainOldData)). Changing this to or_else doesn't do anything for performance.