hashbrown has a hard time compiling against libcore now

[CryZe]

error[E0599]: no method named `entry` found for type `hashbrown::map::HashMap<rusttype::GlyphId, M>` in the current scope
  --> livesplit-core\src\rendering\glyph_cache.rs:31:21
   |
31 |         self.glyphs.entry(glyph).or_insert_with(|| {
   |                     ^^^^^
   |
   = note: the method `entry` exists but the following trait bounds were not satisfied:
           `hashbrown::map::DefaultHashBuilder : core::hash::BuildHasher`

ed0b240 still builds. So it's either the raw API or more likely AHash that broke it.

[CryZe]

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.

[Amanieu]

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

cc @tkaitchuck

[Amanieu]

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

[tkaitchuck]

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

[dtolnay]

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?

[Amanieu]

@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.

[dtolnay]

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.

[CryZe]

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)

[tkaitchuck]

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.

[Amanieu]

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

[tkaitchuck]

@Amanieu Merged and pushed to github and cargo

[Amanieu]

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.