[Pkg-rust-maintainers] Bug#931002: rust-coresimd: FTBFS (unrecognized platform-specific intrinsic function: `x86_rdrand16_step`unrecognized platform-specific intrinsic function: `x86_rdrand16_step`)

[Henri Sivonen]

> For future release, a better way of handling this will be needed. The fact
> that these updates break random other packages isn't really acceptable.

The fix in sid involved patching encoding_rs 0.8.15, which addressed
the simd crate problem. The reason why simd complied previously and
got packaged is explained by the build.rs hack in the simd crate.
Upstream encoding_rs 0.8.16 no longer depends on the simd crate and
instead depends on packed_simd, which doesn't have such a hack.
Indeed, the hack was recognized as problematic upstream, and the
present the harmlessness of the hack in encoding_rs's own build.rs now
depends on the build failing in packed_simd when using the stable
compiler.

As reported, the failures were not only in the simd crate but also in
coresimd, which was pulled in by packed_simd, which was pulled in as
an optional dependency of the bytecount crate. None of these three
crates have the build.rs hack, so the build for packed_simd and
coresimd should have failed even before the recent rustc update in sid
and buster.

Indeed, if I try to build the corresponding upstream versions of
bytecount and packed_simd with by invoking
cargo build --features generic-simd
from the bytecount directory locally with Rust 1.32 from rustup, the
build fails in packed_simd due to use of unstable features.

In the interest of avoiding future breakage, it would be particularly
worthwhile investigate how it was possible that packed_simd and
coresimd made it through the import as optional dependencies of
bytecount and compiled with the previous compiler when they shouldn't
have compiled. (Also: Why does the newly-uploaded version of
packed_simd in sid compile now?)

-- 
Henri Sivonen