Stream: git-wasmtime

Topic: wasmtime / issue #7896 Wasmtime does not compile on the l...

Wasmtime GitHub notifications bot (Feb 08 2024 at 14:35):

alexcrichton opened issue #7896:

The latest oss-fuzz build failed here and it's because the ahash crate at 0.8.2 no longer builds on the latest nightly. This appears to be due to the fact that the crate's build script is automatically enabling a feature that is no longer present in nightly Rust.

Updating to v0.8.7 finishes a build correctly, but this update also pulls in a new dependency on a crate called zerocopy which itself depends on zerocopy-derive. The derive macro is ~1kloc and generates a good deal of unsafe code and the zerocopy crate itself is also quite large and contains a lot of unsafe code with a lot of fiddling. Basically this one is not going to be an easy vet.

I wanted to open an issue on this though to track what to possibly do.

One option is to perhaps try to remove this dependency. This comes through the hashbrown crate and it appears optional so we may be able to remove it, but I'm also not sure if we specifically rely on this being a more performant hash than the otherwise default-selected.

Wasmtime GitHub notifications bot (Feb 08 2024 at 15:17):

bjorn3 commented on issue #7896:

The zerocopy-derive dependency only happens when the derive feature of zerocopy is enabled, which ahash doesn't enable. It is a cargo bug that the lockfile contains it anyway.

Wasmtime GitHub notifications bot (Feb 10 2024 at 04:39):

abrown closed issue #7896:

The latest oss-fuzz build failed here and it's because the ahash crate at 0.8.2 no longer builds on the latest nightly. This appears to be due to the fact that the crate's build script is automatically enabling a feature that is no longer present in nightly Rust.

Updating to v0.8.7 finishes a build correctly, but this update also pulls in a new dependency on a crate called zerocopy which itself depends on zerocopy-derive. The derive macro is ~1kloc and generates a good deal of unsafe code and the zerocopy crate itself is also quite large and contains a lot of unsafe code with a lot of fiddling. Basically this one is not going to be an easy vet.

I wanted to open an issue on this though to track what to possibly do.

One option is to perhaps try to remove this dependency. This comes through the hashbrown crate and it appears optional so we may be able to remove it, but I'm also not sure if we specifically rely on this being a more performant hash than the otherwise default-selected.

Last updated: Oct 23 2024 at 20:03 UTC