or_fun_call lint shouldn't ignore indexing to HashMap types

[tesuji]

See also the perf improvement in rustc: rust-lang/rust#78508.

Currently, or_fun_call lint doesn't lint on indexing to HashMap types.

I tried this code:

#![warn(clippy::or_fun_call)]
use std::collections::HashMap;
pub fn foo(opt: Option<u32>, map: HashMap<u32, u32>, idx: u32) -> u32 {
    opt.unwrap_or(map[&idx])
}

I expected to see this happen: A warning to unwrap_or method call because
map[&idx] maybe expensive (indexing to a hashmap).

Instead, this happened: No warning at all.

Meta

• cargo clippy -V: 0.0.212 (2020-10-28 31ee872) from playground
• rustc -Vv: (2020-10-28 31ee872)

Maybe a duplicate of #5821 .

[camsteffen]

map[&idx] is syntactic sugar for map.index(&idx) (a function call). The specific type of map doesn't really matter.

[ghost]

Should all indexing be linted or specifically indexing HashMap types? Is it OK to index a Vec?

[tesuji]

I would like to exclude Vec, slice and array types since indexing into those types
is usually just a pointer arithmetic and a dereference.

[camsteffen]

Excluding slices seems arbitrary to me. If it is not const, why would you not defer it? Especially since the lambda will be inlined. Also indexing a slice includes a bounds check and is fallible.

However, the lint is named or_fun_call and not or_non_const. Perhaps that could be a separate lint? I think we need more input here.

[giraffate]

@rustbot modify labels: +L-enhancement