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 https://github.com/rust-lang/rust/pull/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\github.com-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\github.com-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: https://github.com/bytecodealliance/wasmtime/issues/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: https://github.com/rust-lang/rust/issues/102260

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