Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upMake the crate `no_std` + `alloc` #44
Conversation
This comment has been minimized.
This comment has been minimized.
|
On regards to your point about having to figure out what to do with the default value of |
This comment has been minimized.
This comment has been minimized.
|
I think we're still missing a couple of important things in #![cfg_attr(not(feature = "std"), no_std)]
#[macro_use]
extern crate cfg_if;
#[cfg(feature = "std")]
extern crate core;
cfg_if! {
if #[cfg(feature = "alloc")] {
extern crate alloc;
} else if #[cfg(feature = "std")] {
extern crate std as alloc;
}
} |
Alright. Are |
This comment has been minimized.
This comment has been minimized.
|
Ah, no, you're right, with the 2018 edition you may be able to remove them. The one thing you will need somewhere is probably this though #[cfg(feature = "std")]
use std as alloc;But could very well be that we can get rid of |
This comment has been minimized.
This comment has been minimized.
The compiler still complains about |
This comment has been minimized.
This comment has been minimized.
|
Hmm, I was thinking of elsewhere in the crate where we try to use |
This comment has been minimized.
This comment has been minimized.
I get a bunch of errors related to the absence of some things auto-imported from I'll work on the auto-imported things. I don't see a clear path on how to deal with |
This comment has been minimized.
This comment has been minimized.
|
I think anything where we take a |
This comment has been minimized.
This comment has been minimized.
|
I am very surprised that CI doesn't catch that it doesn't compile with |
This comment has been minimized.
This comment has been minimized.
|
It looks like it doesn't even re-compile when |
This comment has been minimized.
This comment has been minimized.
Yep. |
This comment has been minimized.
This comment has been minimized.
|
If you do the following locally, in order, do you get any errors? $ cargo check --all --bins --examples
$ cargo check --all --bins --examples --no-default-features |
This comment has been minimized.
This comment has been minimized.
|
As in, just do: # -> SkipMap<K, V> {
SkipMap {
inner: base::SkipList::new(epoch::default_collector().clone()),
}
} |
This comment has been minimized.
This comment has been minimized.
|
That does mean that methods cannot generally return references though, right? Since you would not be able to give the return value an appropriate lifetime, as it would be tied to the guard we construct inside each method. That's pretty unfortunate. |
This comment has been minimized.
This comment has been minimized.
|
That is, in the high-level type. In the low-level type you can still take a |
This comment has been minimized.
This comment has been minimized.
|
A newtype Two of the motivations for #45 are |
This comment has been minimized.
This comment has been minimized.
|
Actually, I have a proposal. Writing it up as an issue as we speak. Will link when written. |
This comment has been minimized.
This comment has been minimized.
|
Okay, for the unsoundness let's continue that conversation in #46. I think this PR is mostly orthogonal to that issue. @GarkGarcia for this PR, I think the main remaining thing is to merge |
This comment has been minimized.
This comment has been minimized.
Could you handle that for me please? |
This comment has been minimized.
This comment has been minimized.
|
Okay, so, I think the next (last?) challenge is that |
This is necessary since there is no particular lock implementation that "makes sense" on `no_std`. This patch changes all types to be generic over any lock type that implements `lock_api::RawMutex`, and defaults to `parking_lot::RawMutex` on `std`. Note that this patch forks the struct definition for `HashMap` into one for `std` (which has a default for `L`) and one for `no_std` (which does not). This is fine since any code written _without_ the `std` feature _will_ compile with the `std` feature enabled (`indexmap` does the same; the reverse is not true). We _could_ introduce an intermediate private struct to avoid repeating the definition, but it would require writing `self.inner` all over the place, which would be sad. This seemed marginally cleaner. Also, this diff makes me want implied bounds a lot: rust-lang/rust#44491
This comment has been minimized.
This comment has been minimized.
|
All right, I fixed that by making us generic over |
This comment has been minimized.
This comment has been minimized.
|
I'll merge this in a few hours unless there are any objections. The |
|
The exposed lock seems like a step too far to me, that perhaps |
| /// See the [crate-level documentation](index.html) for details. | ||
| pub struct HashMap<K, V, S = RandomState> { | ||
| #[cfg(feature = "std")] | ||
| pub struct HashMap<K, V, L = parking_lot::RawMutex, S = RandomState> |
This comment has been minimized.
This comment has been minimized.
cuviper
Jan 30, 2020
Collaborator
I suggest L and S should be reversed, so HashMap<K, V, S> still looks like the standard collection. This would also simplify the test cases where you had to start specifying the lock type to use a different hasher, which feels like an API wart. However, that means you'd have to remove the default S in the no-std configuration too.
This comment has been minimized.
This comment has been minimized.
jonhoo
Jan 30, 2020
Owner
Yeah, not wanting to remove the default S in no-std is why I ordered them this way. I'm honestly not sure which is better/worse. My inclination is to make things harder for no_std folks when given a trade-off, which would suggest no defaults in no-std and L last.
|
|
||
| /// An iterator over a map's entries. | ||
| /// | ||
| /// See [`HashMap::iter`](crate::HashMap::iter) for details. | ||
| #[derive(Debug)] | ||
| pub struct Iter<'g, K, V> { | ||
| pub(crate) node_iter: NodeIter<'g, K, V>, | ||
| pub struct Iter<'g, K, V, L> |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
jonhoo
Jan 30, 2020
Owner
Bah, then we'd have to duplicate all of these too. One other option here is to define a default value on no_std that panics when used. It ain't great at all, but it would allow us to not duplicate all the structs.
This comment has been minimized.
This comment has been minimized.
cuviper
Jan 30, 2020
Collaborator
I suppose that's why hashbrown uses an uninhabited default on no-std.
This comment has been minimized.
This comment has been minimized.
Amanieu
Jan 30, 2020
No, hashbrown uses ahash on no_std. It only uses an uninhabited default when compiled as a dependency for libstd (because the libstd build system is weird and makes dependencies difficult).
This comment has been minimized.
This comment has been minimized.
cuviper
Jan 30, 2020
Collaborator
Oh ok, I misunderstood that context, and hashbrown doesn't need a lock like this. An uninhabited default might still work though, or we could use macro_rules! to hide the duplication.
This comment has been minimized.
This comment has been minimized.
|
I don't disagree with you that the change is becoming pretty painful API-wise. I've put out a call for input from the people who actually use If we decide it's not worth it, then I still think there are a bunch of changes from this PR we may want to adopt in |
GarkGarcia commentedJan 29, 2020
This is far from complete, but I went ahead and replaced
stdforcorein all of the easy places. I also created thestdfeature and configured all relevant functions to only be exposed when using it.I'd like some input before I proceed.