cap-primitives no longer builds on Nightly for Windows

[repi]

Not sure when Nightly introduced a change that broke the compilation of cap-primtives here, I'm on latest from today cargo 1.64.0-nightly (85b500cca 2022-07-24).

latest stable (1.62) and beta (1.63.0-beta.7) works fine.

this is the error one runs into when building with Nightly:

error[E0277]: the trait bound `file_type::FileType: std::sealed::Sealed` is not satisfied
   --> cap-primitives\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`

Repro:

• cargo +nightly build --workspace

[ChrisDenton]

FileTypeExt was stabilized and sealed in rust-lang/rust#98583

[philpax]

I can confirm that #271 resolves the compilation issue for me:

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

[philpax]

Bah, caveat - the patch + wasmtime 0.39.1 works on Windows if you just patch cap-primitives, but fails on macOS due to cap-fs-ext expecting the new traits. Bringing in cap-fs-ext as well results in build errors from wasi-cap-std-sync (part of wasmtime):

error[E0599]: no method named `open_dir_nofollow` found for struct `cap_std::fs::Dir` in the current scope
  --> .cargo\registry\src\git.colasdn.top-1ecc6299db9ec823\wasi-cap-std-sync-0.39.1\src\dir.rs:87:20
   |
87 |             self.0.open_dir_nofollow(Path::new(path))?
   |                    ^^^^^^^^^^^^^^^^^ method not found in `cap_std::fs::Dir`

error[E0599]: no method named `full_metadata` found for struct `cap_std::fs::DirEntry` in the current scope
   --> .cargo\registry\src\git.colasdn.top-1ecc6299db9ec823\wasi-cap-std-sync-0.39.1\src\dir.rs:160:34
    |
160 |                 let meta = entry.full_metadata()?;
    |                                  ^^^^^^^^^^^^^

etc

So not quite a drop-in solution yet for those using wasmtime 0.39.1 + wasmtime-wasi on a nightly from the last two weeks, but getting there. I think it should be possible for me to fork wasmtime and make the relevant patches there, and that should hopefully get me across the line.

Disregard, just needed to patch cap-std as well:

[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" }

[pinkforest]

Sealed ended up into 1.64.0 stable

EDIT: I've summarized and continuing this in: bytecodealliance/wasmtime#4957

This is now a problem on stable now for Windows and the patch breaks it for unix.

[sunfishcode]

It doesn't break unix. The problem in that issue is that there's a mix of both 0.25.5 and 0.25.2.

[pinkforest]

Hmm yeah this is why I hate patching as the lock can be unstable and the patch-branch essentially has to have matching version

Can we do recursive point-release proper for 0.40 users to fix this ?

[sunfishcode]

If it's possible to reproduce a problem using unpatched wasi-common 0.40 and Rust stable, it may make sense to consider a point release.

[pinkforest]

If it's (sealed FileTypeExt) not indeed in 1.64 yet this willl be most probably end up 1.65 stable given the issue was stabilised..

I traced down the exact changes in std and the intent here was to stabilise it via windows_file_type_ext: rust-lang/rust#102260

I'll check the release and see if libs are going to hold it or revert it...