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

HashMap<K,V> is always Send/Sync #21763

Closed
talchas opened this issue Jan 30, 2015 · 6 comments · Fixed by #21768
Closed

HashMap<K,V> is always Send/Sync #21763

talchas opened this issue Jan 30, 2015 · 6 comments · Fixed by #21768

Comments

@talchas
Copy link

talchas commented Jan 30, 2015

trait Foo: Send {}
impl Foo for HashMap<Rc<()>, Rc<()>> {}

This compiles, despite Rc : !Send. I'm guessing this is because RawTable only uses K and V with marker::CovariantType, and I guess that isn't enough for the negative-impl to propagate. I haven't checked which other collections might be unsafe.

@alexcrichton alexcrichton added O-Arm Target: 32-bit Arm processors (armv6, armv7, thumb...), including 64-bit Arm in AArch32 state I-nominated and removed O-Arm Target: 32-bit Arm processors (armv6, armv7, thumb...), including 64-bit Arm in AArch32 state labels Jan 30, 2015
@alexcrichton
Copy link
Member

It appears that this also isn't specifically related to trait bounds:

use std::collections::HashMap;
use std::rc::Rc;
fn foo<T: Send>() {}
fn main() {
    foo::<HashMap<Rc<()>, Rc<()>>>();
}

cc @gankro, @pczarn, @cgaebel,

@Gankra
Copy link
Contributor

Gankra commented Jan 30, 2015

Ah, yeah. RawTable contains only a Unique<u8>, which is of course always Send/Sync. It should presumably just contain a plain *mut u8 and impl Send/Sync conditionally?

@Gankra
Copy link
Contributor

Gankra commented Jan 30, 2015

Or we need a more rich marker type.

@alexcrichton
Copy link
Member

rust-lang/rfcs#738 may be a good replacement for the current system as it could contain a marker of Vec<K> and Vec<V> for example. For now though a manual impl of Send and Sync will probably be required.

Should other collections with an unsafe representation also be audited?

@Gankra
Copy link
Contributor

Gankra commented Jan 30, 2015

I can say confidently this is the only problem case in collections. It's the only collection that uses basically a void pointer.

@alexcrichton
Copy link
Member

ok cool, good to know!

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

Successfully merging a pull request may close this issue.

3 participants