ZSTD_c_experimentalParam6 is missing in zstd-sys 2.0.10

[wtdcode]

error[E0432]: unresolved import `zstd_sys::ZSTD_cParameter::ZSTD_c_experimentalParam6`
   --> /home/mio/.cargo/registry/src/index.crates.io-6f17d22bba15001f/zstd-safe-6.0.6/src/lib.rs:609:13
    |
609 |             ZSTD_c_experimentalParam6 as ZSTD_c_targetCBlockSize,
    |             -------------------------^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |             |
    |             no `ZSTD_c_experimentalParam6` in `ZSTD_cParameter`
    |             help: a similar name exists in the module: `ZSTD_c_experimentalParam1`

[gyscos]

Hi! Yes, this experimental parameter was promoted to non-experimental in this release.
Experimental parameters are behind the "experimental" feature flag, and as the name suggest, may go through breaking changes in regular releases. Were you using this feature?

The easiest solution would be to update your version of zstd-safe.

[wtdcode]

Hi! Yes, this experimental parameter was promoted to non-experimental in this release. Experimental parameters are behind the "experimental" feature flag, and as the name suggest, may go through breaking changes in regular releases. Were you using this feature?

The easiest solution would be to update your version of zstd-safe.

I can't control this crate as it's a subdependency. My temporary workaround is using patch.crates-io

[gyscos]

You can also lock zstd-sys to 2.0.9, the last version with this experimental value.

Do you know which dependency is enabling this feature? It might be a good idea to have it pin the version of zstd-sys if it really needs these experimental parameters.

[ralexstokes]

just to chime in, I had the exact same problem with some caveats below. found a fix here: https://github.com/ralexstokes/ethereum-consensus/pull/360/files#diff-0219ba3c813ee31a0ca2d8c440d9f100c5e53b68a57ec2f57f73e36032511d59R72 by just disabling the feature

1. no Cargo.lock in this repo, as it is a library, but then CI would pull the latest zstd set of crates
2. this dep was in this repo just for some non-important examples and so I could easily just disable the feature
3. luckily the culprit was a direct dependency so I could just disable directly, and luckily the dependency crate had a feature flag for zstd functionality (both of these could not have been the case!)

[gyscos]

Note that you can always add zstd-sys as a dependency with a fixed version in Cargo.toml, no need for Cargo.lock.

[patowen]

One such dependency that uses it is ztd-safe version 6.0.6 (from this repo) when the experimental feature flag is enabled.