Fix free lifetime vars in HashMap's iterators

[pczarn]

Fixes #17500

[rust-highfive]

Warning

• These commits modify unsafe code. Please review it carefully!

[Gankra]

This just drops the marker, I guess?

[alexcrichton]

When we end up moving to randomized layout for all structure not marked #[repr(C)], this may cause this transmute to go awry. Could this take a similar strategy as vectors and transmute to a 'static lifetime?

[pczarn]

The type checker requires 'static bounds on parameters otherwise, just like in Vec.

688:27 error: the parameter type `K` may not live long enough; consider adding an explicit lifetime bound `K:'static`...
688:27 note: ...so that the reference type `&collections::hashmap::table::RawTable<K,V>` does not outlive the data it points at

Edit: will do.

[Gankra]

I think it might also be appropriate to include a compile-fail for the original error case:

fn main() {
    let mut my_stuff = std::collections::HashMap::new();
    my_stuff.insert(0i, 42i);

    let (_, thing) = my_stuff.iter().next().unwrap();

    my_stuff.clear(); // Error: cannot borrow while `thing` still exists

    println!("{}", *thing);
}

Edit: presumably you confirmed this doesn't work anymore?

[pczarn]

Done. Added that test case which is a little different. Other collections don't elide lifetimes in fn iter, is there a reason not to do this?

[Gankra]

At least for anything I've touched, I wasn't aware that you could elide lifetimes in types. I'm guessing most everywhere else is legacy.

[aturon]

cc @nikomatsakis

[nikomatsakis]

On Wed, Sep 24, 2014 at 12:17:25PM -0700, Aaron Turon wrote:

cc @nikomatsakis

This just emphasizes I need to rebase my branch implementing variance
and making this sort of bivariance illegal.