Increasing minumum supported rust version occured by rkyv and hashbrown

[brew0722]

Describe the bug

Close: CosmWasm/cosmwasm#1244 Finschia/cosmwasm#174

Since the rkyv dependency referenced by several subpackages of wasmer is not pinned,
so the rkyv version is automatically incremented in the cargo.lock.

However, as the version of rkyv increases to v0.7.36, the version of rust must be raised.
because of Hashbrown 0.12.0 used in the latest version of rkyv requires rust edition2021.
So the original wasmer 2.2.0 should be compilable with rust 1.54.0,
but because of this problem, compiling elsewhere is not possible.

Until fix, we should present a guide to downgrade rkyv to new project with all dependencies.

user@AL01696733 burner % cargo +1.54.0 test   
error: failed to download `hashbrown v0.12.0`

Caused by:
  unable to get packages from source

Caused by:
  failed to parse manifest at `/Users/user/.cargo/registry/src/github.com-1ecc6299db9ec823/hashbrown-0.12.0/Cargo.toml`

Caused by:
  feature `edition2021` is required

  this Cargo does not support nightly features, but if you
  switch to nightly channel you can add
  `cargo-features = ["edition2021"]` to enable this feature
user@AL01696733 burner % 

    │   ├── wasmer-compiler v2.2.0
(...)
    │   │   ├── rkyv v0.7.36
(...)
    │   │   │   ├── hashbrown v0.12.0

So could you please pin the version of rkyv? Like wasmer's subpackages("=2.2.0).

wasmer/lib/compiler/Cargo.toml

Line 24 in 8b9af9b

rkyv = { version = "0.7.20", optional = true }

wasmer/lib/engine-dylib/Cargo.toml

Line 26 in 8b9af9b

rkyv = "0.7.20"

wasmer/lib/engine-universal/Cargo.toml

Line 27 in 8b9af9b

rkyv = "0.7.20"

wasmer/lib/types/Cargo.toml

Line 17 in 8b9af9b

rkyv = { version = "0.7.20", optional = true }

wasmer/lib/vm/Cargo.toml

Line 24 in 8b9af9b

rkyv = { version = "0.7.20", optional = true }

[syrusakbary]

Sounds reasonable!

[Amanieu]

Wasmer only guarantees support for the last 2 stable versions of Rust. You can see Wasmer's MSRV in the rust-toolchain file in the git repository, it is currently 1.56. In the near future we will be increasing the MSRV to 1.59 to use new language features (inline assembly).

[brew0722]

@Amanieu
I understand your opinion.

Bu,t I think this is not just an inherent problem with wasmer 2.2.0. I have the same problem with wasmer 2.0.0.
wasmer 2.0.0 MSRV is 1.51.0. Others using wasmer 2.0.0 will require msrv to be 1.55.0 or higher because of this issue.

Regardless of the current MSRV, if wasmer don't pin the dependencies version, it is expected that older versions in the future will continue to have similar problems.

For example, suppose rkyv is updated in the future so that msrv required 1.60.0. Wasmer 2.2.0's msrv was specified as 1.56.0, but it will be raised due to this problem again.
So in the future, what should we call the msrv of wasmer 2.2.0?
in other places that use wasmer, we have to force a lower dependency every time you go up.

[webmaster128]

Unfortunately this is an unresolved ecosystem-wide problem. I highly recommend taking the time to read all of rust-lang/api-guidelines#252, which was very helpful to me. It's a back and forth between You can't simply break other people's projects that compiled once with compiler X on the one side and well, stability guarantess? Whatever! Give it up because there is always this one dude in the dependency tree that requires a recent Rust version for some reason if any.

CosmWasm tries to establish compiler support guarantees and we currently cannot easily upgrade beyond 1.55.0 for very custom reasons. But we are failing for the reasons described above.

[jcaesar]

I don't think wasmer should fix a maximum version for rkyv. Suppose rkyv releases some important bugfix. If wasmer requires a specific version, dependencies of wasmer wouldn't be able to use the rkyv bugfix release without an update from wasmer first.

Would adding a dependency like

rkyv = { version = "<0.7.36" }

to cosmwasm take care of the problem?

(Sorry, none of my business, but I did feel the need to mention the downsides of wasmer fixing this problem for cosmwasm.)

[webmaster128]

I agree there is very little Wasmer can or should do about it. It's a Rust ecosytsem mess and we have the same problem potentially for each and every dependency. We see many projects even bumping their compiler requirements in a patch release.

I work around it by manually adjusting lockfiles. For our users there is little we can do to provide a stable min compiler version.

[brew0722]

I agree that this is essentially a problem on the rust eco system side.
And I also understand that it is some W/A to pin rkyv for supporting the MSRV.
So I understand that it is difficult for wasmer to guarantee MSRV. Please close this issue if there are no other comments.

to cosmwasm take care of the problem?

However,Solving with W/A in the cosmwasm project is not completely solved the problem yet.
This is because the cargo.lock of the newly created contract package cannot be pinned rkyv by cosmwasm package(*).
After all, we should always guide contract developers (wasm binary developers) how to pin the rkyv. Otherwise we should ignore MSRV and force contract developers to use the latest version of rust.

--
(*) The reason linking cosmwasm-vm and wasmer in the wasm package is because of the dev-dependencies for testing. So if using the rust version is lower, wasm compilation is fine, but the test fails.

[syrusakbary]

It seems we should be good to close the issue, since there's little we can do on our side.

But if anyone else has more suggestions on what can be done on our side please feel free to add a comment