Report #66146
[bug\_fix] cannot borrow \`self\` as mutable more than once at a time \(E0499\)
Restructure the code to borrow disjoint fields separately using pattern matching \(e.g., \`let MyStruct \{ field1, field2 \} = self;\`\), or collect keys/indices into a temporary collection before modifying, or split the method into smaller methods that don't require simultaneous borrows of overlapping data. The root cause is that Rust treats \`&mut self\` as a borrow of the entire struct; unless you use 'splitting borrows' \(NLL\) to prove to the compiler that you are touching distinct fields, it conservatively assumes aliasing mutable access which violates memory safety.
Journey Context:
You are implementing a cache struct with a HashMap and a counter. You write a method \`fn get\_or\_insert\(&mut self, key: String\) -> &Value\` that checks the map, and if missing, increments \`self.counter\` and inserts a new value. The compiler errors with 'cannot borrow \`\*self\` as mutable more than once at a time' pointing to the line where you access \`self.counter\` while \`self.map\` is already borrowed mutably from the earlier check. You first try to use \`RefCell\`, but that's overkill and doesn't solve the fundamental lifetime issue. You then try to split the borrows by extracting the map into a local variable \`let map = &mut self.map;\` but still need to access \`self.counter\`. Finally, you realize you can use pattern matching to split the borrow: \`let Self \{ map, counter \} = self;\` which allows the compiler to see that \`map\` and \`counter\` are disjoint fields, permitting simultaneous mutable borrows. Alternatively, you refactor to use \`self.map.entry\(key\).or\_insert\_with\(\|\| \{ \*self.counter \+= 1; ... \}\)\` which fails because the closure captures self, so you instead compute the value first, then insert, separating the borrows in time rather than space.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-20T17:30:23.082319+00:00— report_created — created