Adapt to portable-simd to_int -> to_simd rename, bump to version 0.6.10

[jieyouxu]

Noticed during a rustfmt subtree sync attempt rust-lang/rustfmt#6807.

Context

portable-simd renamed to_int to to_simd in rust-lang/portable-simd#478 due to a common confusion (rust-lang/portable-simd#477), so bytecount with generic-simd against later nightlies fail to build.

With this patch, bytecount with generic-simd feature successfully builds on a x86_64-unknown-linux-gnu host against latest nightly rustc 1.95.0-nightly (c04308580 2026-02-18).

cargo check --features=generic-simd --all-targets

Review notes

• Split into two commits. Commit 1 does a minimal change to fix the renamed method (to_simd). Commit 2 bumps the version to 0.6.10 and updates the version referenced in the README.
• Intentionally did not run rustfmt, since it seems that the code behind generic-simd were not previously ran through rustfmt.
• This will need a new point release. I don't know how the CI works for this particular repo. I only checked locally that it check-builds.

[jieyouxu]

Hm, I think this part in the README

Versions from 0.6.0 require Rust 1.32.0 or later.

Is also not quite accurate (for the last generic-simd fix as well as this one), since when the portable-simd stuff gets renamed it's not backwards-compatible with older Rust toolchains. This particular PR would raise the "MSRV" of the generic-simd to the nightly toolchain that contains rust-lang/portable-simd#478.

Let me know if you want me to also update that particular description.

[xtqqczze]

@llogiq PTAL

[luissantosHCIT]

Crate version on crates.io is still 0.6.9. The copy that gets pulled does not contain the to_int -> to_simd updates applied here. Would it be possible to push a new crate release reflecting the function rename?

My Opinion: If the question is whether to provide backwards compatibility with older toolchains, I think bumping the minor version should help make clear there is a disrupting change such as raising the MSRV. Since the portable simd feature is technically unstable, supporting it implies your minimum supported compiler version is whatever minimum nightly version that does not break compilation or functionality. It's annoying but that is part of supporting an unstable feature, unfortunately.