wasmtime 1.0.0's wasi-cap-std-sync doesn't compile with nightly Rust on Windows

[philpax]

Steps to Reproduce

• Update to a Rust nightly after the 27th of July
• Attempt to build wasmtime-wasi

Expected Results

The build completes successfully.

Actual Results

The build fails as the version of cap-std in use uses sealed traits in the Rust stdlib:

   --> C:\Users\me\.cargo\registry\src\git.colasdn.top-1ecc6299db9ec823\cap-primitives-0.25.3\src\fs
\file_type.rs:134:6
    |
134 | impl std::os::windows::fs::FileTypeExt for FileType {
    |      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `std::sealed::Sealed` is not 
implemented for `file_type::FileType`
    |
    = help: the following other types implement trait `std::sealed::Sealed`:
              Child
              Command
              ExitCode
              ExitStatus
              ExitStatusError
              OsStr
              OsString
              Simd<f32, N>
            and 2 others
note: required by a bound in `std::os::windows::fs::FileTypeExt`

Versions and Environment

Wasmtime version or commit: 1.0.0

Operating system: Windows 10

Architecture: x86-64

Extra Info

This is caused by bytecodealliance/cap-std#270, which has been fixed up by upstream cap-std. A v0.26.0-patch1 has been released that includes this fix, but it may be worth waiting for the 1.0.0? (not sure what y'all are planning internally.)

Prior to this, I was using wasmtime 0.39.1 with these patches:

[patch.crates-io]
cap-std = { git = "https://github.com/bytecodealliance/cap-std.git", branch = "sunfishcode/file-type-ext" }
cap-primitives = { git = "https://github.com/bytecodealliance/cap-std.git", branch = "sunfishcode/file-type-ext" }
cap-fs-ext = { git = "https://github.com/bytecodealliance/cap-std.git", branch = "sunfishcode/file-type-ext" }

As wasmtime 1.0.0 depends on 0.25.3 specifically, I can no longer manually patch the relevant packages as there's no version of 0.25.3 with this fix on the Git repository, and (as far as I can tell, it's still a little mysterious to me) there's no way to patch with another version from crates.io (I'd patch with 1.0.0rc1 if it was possible)

This is currently blocking us from updating to 1.0.0; 0.39.1 still works fine, but would love to get in today's release hype 🚀

[sunfishcode]

I think it makes sense to do a cap-std 0.26 release, with the fix, and update wasmtime to use that. I've now filed bytecodealliance/cap-std#275 with more info.

[philpax]

Seems reasonable - thank you for the speedy response! ❤️

[philpax]

Aye, that's what I suspected - but is it possible to backport this under the bugfix policy? As far as I can tell, this is the only thing blocking us from updating to 1.0.

[pchickey]

In my judgement, failing to build under Nightly doesn't meet the bar of "on-by-default behavior", though the RFC itself doesn't make that explicit. Nightly builds tend to break pretty often (once a month? more?) and it would be burdensome if we did a point release for all of them. Sorry to be the person to say no.

[sunfishcode]

@philpax One workaround would be to pin to a nightly Rust version from before rust-lang/rust#98583 landed.

Another workaround: If you'd like, I could create git branches of cap-std which have the fix and have a 0.25.3 version number. I can't publish those to crates.io because the fix is semver-incompatible with 0.25, but since you mentioned using git = dependencies above, if you could use a git = dependency on such a branch, that would be another workaround. Would that be helpful?

Also, part of the Wasmtime 1.0 announcement is that Wasmtime has a monthly release cadence, so in a month, we'll have a new release with the actual fix in it.

[philpax]

In my judgement, failing to build under Nightly doesn't meet the bar of "on-by-default behavior", though the RFC itself doesn't make that explicit. Nightly builds tend to break pretty often (once a month? more?) and it would be burdensome if we did a point release for all of them. Sorry to be the person to say no.

Understandable, I'll make it work.

One workaround would be to pin to a nightly Rust version from before rust-lang/rust#98583 landed.

Aye - unfortunately, we're using changes from after that nightly, so we're tied to it.

Another workaround: If you'd like, I could create git branches of cap-std which have the fix and have a 0.25.3 version number. I can't publish those to crates.io because the fix is semver-incompatible with 0.25, but since you mentioned using git = dependencies above, if you could use a git = dependency on such a branch, that would be another workaround. Would that be helpful?

That would be fantastic if possible! I'm more than happy to use a Git patch - that should resolve the issue for me until we can use 2.0.0 🙂

[sunfishcode]

Ok, I've now created a 0.26-with-a-0.25-version-number branch, which is the 0.26 branch with one patch applied, to change the version number to 0.25.4-backport0. Let me know if that doesn't work!

[philpax]

Thanks! Unfortunately, it appears Cargo is intensely picky about how it decides to pick minor versions for patches, and will refuse to update 0.25.3 to 0.25.4-backport0 (but will update 0.25.3 to 0.25.4, which I validated by making that change to your branch locally)

I'm wrapping up my week, so I'm in no particular hurry for a fix. Based on my experimentation, I think you would have to drop the -backport0 to make Cargo consider it as a viable candidate as a patch.

I don't want to take up too much of your time / make things too confusing on your end, so I'm happy to just maintain a 0.25.4-versioned fork of cap-std under our org for the next month (esp as you've shown that 0.26 is 0.25-compatible for wasmtime). Does that work for you?