Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Does not build on latest nightly w/ RFC 509 #21

Closed
drbawb opened this issue Jan 6, 2015 · 4 comments
Closed

Does not build on latest nightly w/ RFC 509 #21

drbawb opened this issue Jan 6, 2015 · 4 comments

Comments

@drbawb
Copy link

drbawb commented Jan 6, 2015

After rust-lang/rust@400c3a0d implemented RFC 509
HashMap::VacantEntry now takes an additional type parameter Sized? Q: ToOwned<K>
The idea being that HashMap#entry() now accepts the key by reference (&'a Q instead of K).
Then VacantEntry calls Q#to_owned() -> K to store it in the map.

I've been trying to fix this; but I'm stumped. In TypeMap: the caller does not generate the TypeId, instead it is generated internally by TypeMap#entry().

Since no reference to this TypeId would live past the call to TypeMap#entry() this invalidates the Entry<'a, K, V> we're trying return.


The best I've been able to do so far is add a helper method that generates the TypeId and returns it to the caller so it lives long enough; then the caller passes it into TypeMap#entry()... but it's a huge loss for ergonomics.

@reem
Copy link
Owner

reem commented Jan 6, 2015

This appears to be a bug in the new Entry API, which requires the key reference to live as long as the map itself. This should be fixed upstream in the near future and there's unfortunately nothing we can really do about it for now.

@Gankra
Copy link

Gankra commented Jan 6, 2015

We're reverting to by-value keys. Should be fixed by the next nightly.

@Gankra
Copy link

Gankra commented Jan 6, 2015

Sorry! 😭

@reem
Copy link
Owner

reem commented Jan 6, 2015

Ok, sounds good. This is only (I think) blocking Iron right now, which is blocked by about 10 other things, so no problem.

@reem reem closed this as completed Mar 9, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants