Repository navigation
Inconsistent borrow check in async function #74068
Description
I tried this code:
use std::collections::HashMap;
fn f1(map: &mut HashMap<i32, String>, k: i32) -> &String {
if let Some(s) = map.get(&k) {
return s;
}
map.insert(k, k.to_string());
map.get(&k).unwrap()
}
async fn f2(map: &mut HashMap<i32, String>, k: i32) -> &String {
if let Some(s) = map.get(&k) {
return s;
}
map.insert(k, k.to_string());
map.get(&k).unwrap()
}f2 seems to be correct but can not be compiled.
Compiling playground v0.0.1 (/playground)
error[E0502]: cannot borrow `*map` as mutable because it is also borrowed as immutable
--> src/lib.rs:15:5
|
12 | if let Some(s) = map.get(&k) {
| --- immutable borrow occurs here
13 | return s;
| - returning this value requires that `*map` is borrowed for `'1`
14 | }
15 | map.insert(k, k.to_string());
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ mutable borrow occurs here
16 | map.get(&k).unwrap()
17 | }
| - return type of generator is &'1 std::string::String
error: aborting due to previous error
For more information about this error, try `rustc --explain E0502`.
error: could not compile `playground`.
To learn more, run the command again with --verbose.
Meta
According to the playground, the problem exists on 1.44.1 and 1.46.0-nightly (2020-07-04 0cd7ff7ddfb75a38dca8).
Other versions may be the same.
Activity
SNCPlay42 commentedon Jul 5, 2020
If
f2is commented out thenf1errors the same way (playground):In rustc 1.42.0 both errors are reported simultaneously (godbolt).
I'm not sure whether this is a bug or not - rustc need not report everything wrong with a crate in one go, but if it can report these simultaneously then it probably should.
SNCPlay42 commentedon Jul 5, 2020
cargo bisect-rustcresults for when the compiler stopped reporting both errors simultaneously:searched nightlies: from nightly-2020-02-06 to nightly-2020-07-05
regressed nightly: nightly-2020-02-16
searched commits: from 433aae9 to 61d9231
regressed commit: 19288dd
Nugine commentedon Jul 6, 2020
I have found the answer.
http://smallcultfollowing.com/babysteps/blog/2018/06/15/mir-based-borrow-check-nll-status-update/
https://nikomatsakis.github.io/rust-belt-rust-2019/#87
How can I work around it without Polonius?Just use Entry API.
tmandry commentedon Jul 7, 2020
Thanks for digging into this, @SNCPlay42! This doesn't appear to be async-related, so removing that tag.
nikomatsakis commentedon Jul 7, 2020
If @SNCPlay42's bisection is correct (thanks!), then this was triggered by #67681 (cc @matthewjasper). It is indeed true that the code example is not expected to compile, though you could make it compile by either using
entryAPI or adding something likeI'm not sure exactly what caused this to occur, but it makes sense that #67681 might be related since that affected how we manage opaque type inference (and the async fn implicitly uses an opaque return type).
matthewjasper commentedon Jul 7, 2020
The error is being suppressed because
rustc_typeck::check_crateis (effectively) aborting compilation early.spastorino commentedon Jul 8, 2020
Prioritized as
P-mediumas per Zulip discussion.compiler-errors commentedon Dec 31, 2024
Both errors are reported now. This is a polonius problem, I believe.