hashbrown has a hard time compiling against libcore now about hashbrown HOT 13 CLOSED

Looks like this is because I had default-features = false, which built successfully against the commit, but not against the published 0.5.1. Also not using default-features now pulls in so many build-dependencies that it enables std most of the time regardless. So yeah, I'll stay on the old commit until I can figure out how to get this to properly compile against no_std again.

from hashbrown.

I yanked 0.5.1. It seems that ahash depends on crates which are not no_std.

cc @tkaitchuck

from hashbrown.

I think that marking the const_random crate with #![no_std] should be sufficient here. Everything else is compiled as a proc macro.

from hashbrown.

It's proc_macro_hack. I've filed an issue here: dtolnay/proc-macro-hack#38
The fix looks simple.

from hashbrown.

Huh? It's fine for the implementation of a proc macro to use std even if the macro is called from crates that are no_std. For example serde_derive supports deriving Serialize and Deserialize in no_std crates but uses plenty of std internally.

Are you trying to write a proc macro where the macro implementation itself is no_std?

from hashbrown.

@dtolnay The issue is that the const_random crate, which uses proc_macro_hack is pulling in libstd. And it seems that this crate is compiled for the target architecture, not the host architecture.

from hashbrown.

The const-random crate is not a proc macro crate, it's fine for that to be no_std and proc-macro-hack supports that just fine. The const-random-macro crate is a proc macro so there should be no reason to make it no_std. A proc macro isn't going to get compiled for the target architecture.

from hashbrown.

It looks like it's just the missing #![no_std] in const-random. proc-macro-hack should not affect anything. (Although the crates pulled in via the proc macro might, due to the cargo bug where features are activated for the target architecture by accident)

from hashbrown.

Ok, we can test that. I've added #![no_std] in const_random 0.1.4 and pushed a version of aHash that specifies this version.

from hashbrown.

@tkaitchuck Did you see my pull request? tkaitchuck/constrandom#2

from hashbrown.

@Amanieu Merged and pushed to github and cargo

from hashbrown.

Unfortunately this still doesn't fix the issue I mentioned in #110:

error: failed to parse manifest at `/home/amanieu/.cargo/registry/src/github.com-1ecc6299db9ec823/const-random-0.1.5/Cargo.toml`

Caused by:
  the cargo feature `public-dependency` requires a nightly version of Cargo, but this is the `stable` channel
See https://doc.rust-lang.org/book/appendix-07-nightly-rust.html for more information about Rust release channels.

from hashbrown.

@Amanieu Fixed in 0.1.6 which is depended on by aHash 0.2.9

from hashbrown.