False positive?: get_unwrap

[Thinkofname]

Link to example: http://play.integer32.com/?gist=2d02b966174279055a9519a5f3182a7d&version=undefined

warning: called `.get().unwrap()` on a HashMap. Using `[]` is more clear and more concise
  --> src/main.rs:24:9
   |
24 |         data.data.get(&key).unwrap().clone()
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: try this `&data.data[&key]`
   |
   = note: #[warn(get_unwrap)] on by default
   = help: for further information visit https://github.com/Manishearth/rust-clippy/wiki#get_unwrap

Honestly seems like the suggested change should work but lifetimes seem to prevent it. Might be because Index and get take slightly different parameter types?

[oli-obk]

that.... is ugly. I'm almost tempted to call it a stdlib bug, but there's probably some reasoning behind it.

get is

fn get<Q: ?Sized>(&self, k: &Q) -> Option<&V> where K: Borrow<Q>, Q: Hash + Eq

while Index is

impl<'a, K, Q: ?Sized, V, S> Index<&'a Q> for HashMap<K, V, S> where K: Eq + Hash + Borrow<Q>,
        Q: Eq + Hash,
        S: BuildHasher
type Output = V
fn index(&self, index: &Q) -> &V

Might be because Index and get take slightly different parameter types?

The only difference I see is the 'a lifetime, which can't really be it. Probably something todo with the indexing desugaring.

Separate bug: the suggestion is wrong (the first ampersand is not correct here)

[Thinkofname]

Looks like its this rustc issue rust-lang/rust#32382

[JelteF]

I'm having this same issue on this line:
https://github.com/JelteF/derive_more/blob/2e37e7f8181ba333df9503088222772b77c83d91/src/from.rs#L103

I'm working around this by manually calling index().

[botahamec]

I can't reproduce the warning. Maybe something changed between then and now?

[giraffate]

Did the #[warn(clippy::get_unwrap)] be added? The get_unwrap is allow-by-default now.