error[E0635]: unknown feature `stdsimd` about ahash

[Kobzol]

It seems that a lot of stuff depends on ahash < 0.8. It would be indeed useful if it was possible to put out a backported patch release for 0.7.

[RalfJung]

Fundamentally this is caused by logic in build.rs that auto-enables a nightly feature when it detects that it is built with a nightly rustc. Such logic is fragile and prone to errors as nightly features evolve before stabilization.

Crates should never automatically enable nightly features, this should generally be opt-in. If they try to do it automatically they need to be very careful and account for the fact that nightly features are not stable, and might look very different in future nightly versions.

I see aHash still does the same kind of auto-detection with the specialize feature. That's a similar issue just waiting to happen.

[mina86]

If you’re on 0.8 branch → update to 0.8.7. See #188.

However, I’m also picking up dependency on 0.7.7 through chain of older dependencies (borsh 0.9 → hashbrown 0.11 → ahash 0.7) which I can’t easily get rid of on my side. It’d be fantastic if we could get backport to 0.7 branch as well. I’ve commented that in #188.

[Kobzol]

This is caused by rust-lang/rust#117372. This problem in ahash was already fixed in #183, which was released in 0.8.7 (it just isn't visible as a GitHub release).

[Kobzol]

Don't forget that you have to cargo update ahash to actually get the newest version (either 0.7.8 or 0.8.7+).

[janu-cambrelen]

For those in this situation and if your workflow permits, pinning the Rust nightly version to an earlier date might serve as a temporary measure to get unblocked, particularly if you're facing the unknown feature 'stdsimd' error with ahash-0.7.7:

# install specific nightly version (i.e., `2024-02-01`)
rustup toolchain install nightly-2024-02-01

# use this nightly version for your commands
cargo +nightly-2024-02-01 build

This is not, of course, a solution to the issue, but rather a workaround that may help in the interim until a more permanent fix is available.

[marvin-bitterlich]

Thank you everyone for the quick resolution!

For folks who have both versions in their deps, here is a quick fix that doesn't require clean:

cargo update [email protected]
cargo update [email protected]

[vikingSec]

Seems like this is breaking trunk and leptos

I was just trying to get into learning leptos, so installing all of the right versions according to the docs and trying to install trunk and cargo-leptos both runs into this bug.

Console output:

> cargo install trunk
error[E0635]: unknown feature `stdsimd`
  --> /Users/medwards/.cargo/registry/src/index.crates.io-6f17d22bba15001f/ahash-0.7.7/src/lib.rs:33:42
   |
33 | #![cfg_attr(feature = "stdsimd", feature(stdsimd))]
   |                                          ^^^^^^^

For more information about this error, try `rustc --explain E0635`.
error: could not compile `ahash` (lib) due to 1 previous error
warning: build failed, waiting for other jobs to finish...
error: failed to compile `trunk v0.18.7`, intermediate artifacts can be found at `/var/folders/9f/w50rg2wj193fh6jv5rt0lk1r0000gn/T/cargo-installif2CRL`.
To reuse those artifacts with a future compilation, set the environment variable `CARGO_TARGET_DIR` to that path. 

Not trying to brigade the comments, I'd work on a fix but you probably don't want a Rust noop running around your repo.

[Manishearth]

Would it be possible to remove the build.rs check in the 0.7 series as @mina86 mentions? 0.8 fixes this but:

• Not everyone has upgraded to it
• This affects MSRV

Fundamentally this is caused by logic in build.rs that auto-enables a nightly feature when it detects that it is built with a nightly rustc. Such logic is fragile and prone to errors as nightly features evolve before stabilization.

I agree with Ralf here: crates shouldn't do this. It makes life harder for crates attempting to support a range of versions: they're either broken on the new version due to the missing feature, or broken on the old version due to an unstable feature.

[tkaitchuck]

Fixed via #201, and released as 0.7.8

[tusharmath]

Facing similar issue.

[tmpfs]

Same here on version 0.7.7, it's broken my crate's documentation build on docs.rs but works fine for me locally on Linux and MacOS, not sure why it's only broken in the docs.rs sandbox environment.

Here is the build log:

https://docs.rs/crate/sos-sdk/0.10.0/builds/1116456

[humb1t]

Same for me

[Manishearth]

Opened #202

Looks like this feature was already disabled in #183

[Kobzol]

Same as #201?

[Manishearth]

Almost. #202 gets us out of the detection business entirely, which is what was already landed in #183

[ozgrakkurt]

Why not juse use crates.io version of the thing or something like that? This is a huge pain, all of the dependencies are littered with this and it is impossible to compile on an M1 with stable toolchain

[Temidayo32]

I am still experiencing the issue. I installed the latest stable

[scambier]

I am still experiencing the issue. I installed the latest stable

Working for me with 0.8.8. Don't forget to cargo clean