Possible false positive “temporary value dropped while borrowed” error

[EFanZh]

I tried this code:

use std::collections::HashSet;

fn main() {
    let mut set = HashSet::from([("abc", 4)]);

    set.remove(&(String::from("abc").as_str(), 4)); // ERROR: temporary value dropped while borrowed.
    set.remove(&(String::from("abc").as_str(), 4)); // OK.
}

I expected to see this happen: The code compiles successfully.

Instead, this happened: I got the follow error:

error[E0716]: temporary value dropped while borrowed
 --> src/main.rs:6:18
  |
6 |     set.remove(&(String::from("abc").as_str(), 4)); // ERROR: temporary value dropped while borrowed.
  |                  ^^^^^^^^^^^^^^^^^^^              - temporary value is freed at the end of this statement
  |                  |
  |                  creates a temporary which is freed while still in use
7 |     set.remove(&(String::from("abc").as_str(), 4)); // OK.
  |     --- borrow later used here
  |
  = note: consider using a `let` binding to create a longer lived value

For more information about this error, try `rustc --explain E0716`.
error: could not compile `scratch` due to previous error

Meta

rustc --version --verbose:

rustc 1.57.0-nightly (addb4da68 2021-09-25)
binary: rustc
commit-hash: addb4da686a97da46159f0123cb6cdc2ce3d7fdb
commit-date: 2021-09-25
host: x86_64-unknown-linux-gnu
release: 1.57.0-nightly
LLVM version: 13.0.0

[SkiFire13]

The error is unfortunately correct. set has type HashSet<(&'a str, 4)>. set.remove takes a Q where T: Borrow<Q>, and unfortunately (&'long str, i32) doesn't implement Borrow<(&'short str, i32)>, so the first String::from("abc").as_str() also gets the type &'a str. 'a now is required to end after the first set.remove(&(String::from("abc").as_str(), 4)); and so is set, however you use it later.

Unfortunately I don't think it's currently possible to write a generic impl for T: Borrow<Q> where Q is a subtype of T, so you're stuck with this error, at least for tuples. You can workaround this by introducing a couple of custom types, although that's far from ergonomic (playground example)

This also looks like the same problem described in #80389

[EFanZh]

But this program does compile:

fn foo<'long: 'short, 'short>(value: (&'long str, i32)) -> impl Borrow<(&'short str, i32)> {
    value
}

Wouldn’t this mean (&'long str, i32) implements Borrow<(&'short str, i32)>?

[SkiFire13]

The return expression of a function is a coercion site, so it's allowed to coerce (&'long str, i32) into (&'short str, i32) and return that. Edit: this doesn't happen in the original snippet of code because (&'long str, i32) is inside the HashSet, which is behind a mutable reference, and that blocks the coercion because mutable references are invariant with respect to the pointed type.

This program avoid the coercion sites by directly passing the types, and as expected it doesn't compile:

fn foo<'long: 'short, 'short>() {
    fn assert_impl_borrow<T: Borrow<Q>, Q>() {}
    assert_impl_borrow::<(&'long str, i32), (&'short str, i32)>();
}

[EFanZh]

Am I understanding this correctly: subtype of T should implement all traits that T implements, so if (&'short str, i32) implements Borrow<(&'short str, i32)>, (&'long str, i32) should also implement Borrow<(&'short str, i32)>. But currently, Rust doesn’t have this feature, so my code does not work.

[SkiFire13]

subtype of T should implement all traits that T implements

Unfortunately that's not always valid, for example with BorrowMut this already becomes unsound: if &'long T implemented BorrowMut<&'short str> then you could get an &mut &'short T that actually points to a &'long T, thus I would be able to write an &'short T to it and then observe it as if it was an &'long T.

IMO what is actually missing is the concept of variance for traits' generic type parameters. The T in Borrow<T> could be covariant, while the one in BorrowMut could be invariant.

[EFanZh]

It seem that there was a time that variance on traits was a thing, but it was removed later:

but it is actually rather subtle in meaning and not that useful in practice, so we removed it.

See https://rustc-dev-guide.rust-lang.org/variance.html#addendum-variance-on-traits.

[BGR360]

@rustbot label +A-variance