`clippy:: map_entry` incorrectly warned on code with a `contains_key` and no `insert`

[erickt]

Summary

Fuchsia just did a dry run roll of Rust rust-lang/rust@5d85a71, and it's incorrectly flagging the clippy::map_entry lint in at least two bits of our code that use contains_key, but do not have a corresponding insert:

• src/connectivity/network/netstack3/src/bindings/filter/conversion.rs

error: usage of `contains_key` followed by `insert` on a `HashMap`
   --> ../../src/connectivity/network/netstack3/src/bindings/filter/conversion.rs:392:17
    |
392 | /                 if self.routine_types.contains_key(&name) {
393 | |                     self.expect_routine_resolved(&name, routine_type, rule_id)
394 | |                 } else {
395 | |                     self.convert_routine(
...   |
401 | |                 }
    | |_________________^
    |
    = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#map_entry
    = note: `-D clippy::map-entry` implied by `-D warnings`
    = help: to override `-D warnings` add `#[allow(clippy::map_entry)]`

• src/devices/lib/driver-static-checks/src/checks.rs:

error: usage of `contains_key` followed by `insert` on a `HashMap`
   --> ../../src/devices/lib/driver-static-checks/src/checks.rs:150:9
    |
150 | /         if json_category.contains_key(&device_category.subcategory) {
151 | |             Ok(StaticCheckPass {})
152 | |         } else {
153 | |             Err(StaticCheckFail  {
...   |
158 | |             })
159 | |         }
    | |_________^
    |
    = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#map_entry
    = note: `-D clippy::map-entry` implied by `-D warnings`
    = help: to override `-D warnings` add `#[allow(clippy::map_entry)]`

Lint Name

clippy:: map_entry

Reproducer

So far I haven't been able to reproduce it outside our code, I'll update if I figure out one.

Version

This was built in our CI/CQ, so it's a little hard to get `rustc -Vv`, but it's with the nightly rustc version https://github.com/rust-lang/rust/commit/5d85a714b10a9121d2ec5115f39e904174f804e1.

Additional Labels

No response

[elenaf9]

We are running into the same issue:

• libp2p/rust-libp2p/protocols/gossipsub/src/peer_score.rs:
  (note that it's params.topics and not self.topics in the first statement)

  error: usage of `contains_key` followed by `insert` on a `HashMap`
     --> protocols/gossipsub/src/peer_score.rs:113:9
      |
  113 | /         if params.topics.contains_key(&topic_hash) {
  114 | |             Some(self.topics.entry(topic_hash).or_default())
  115 | |         } else {
  116 | |             self.topics.get_mut(&topic_hash)
  117 | |         }
      | |_________^
      |

• libp2p/rust-libp2p/protocols/gossipsub/src/behaviour.rs:

  error: usage of `contains_key` followed by `insert` on a `HashMap`
      --> protocols/gossipsub/src/behaviour.rs:1816:9
       |
  1816 | /         if self.mesh.contains_key(&message.topic) {
  1817 | |             tracing::debug!("Sending received message to user");
  1818 | |             self.events
  1819 | |                 .push_back(ToSwarm::GenerateEvent(Event::Message {
  ...    |
  1829 | |             return;
  1830 | |         }
       | |_________^

Version

clippy 0.1.87 (45165c82a4 2025-04-01) (current beta)

[meithecatte]

Minimal example (playground):

use std::collections::BTreeMap;
pub struct Meow {
    map: BTreeMap<String, String>,
}

impl Meow {
    fn pet(&self, _key: &str, _v: u32) -> u32 {
        42
    }
}

pub fn f(meow: &Meow, x: String) {
    if meow.map.contains_key(&x) {
        let _ = meow.pet(&x, 1);
    } else {
        let _ = meow.pet(&x, 0);
    }
}

[meithecatte]

searched nightlies: from nightly-2025-03-17 to nightly-2025-04-08
regressed nightly: nightly-2025-03-22
searched commit range: rust-lang/rust@78948ac...be73c1f
regressed commit: rust-lang/rust@5d85a71

bisected with cargo-bisect-rustc v0.6.9

Host triple: x86_64-unknown-linux-gnu
Reproduce with:

cargo bisect-rustc --component clippy -- clippy

[meithecatte]

git bisect identifies 18616dc as the first bad commit. cc @profetia