Stream: git-wasmtime

Topic: wasmtime / issue #4957 Broken Windows builds via < 1 (or ...


view this post on Zulip Wasmtime GitHub notifications bot (Sep 25 2022 at 13:49):

pinkforest edited issue #4957:

Problem now is that anyone using 0.40 e.g. via wasi-common will get 0.25 cap-std

         ├── wasi-common v0.40.0
            ├── cap-rand v0.25.2
            ├── cap-std v0.25.2
               ├── cap-primitives v0.25.2

And therefore incompat cap-primitives in Windows when using stable > 1.64.0 rust stable that has sealed the FileTypeExt trait

By doing nothing this still works on at least unix but Windows is now broken on it's default state doing nothing on rust stable 1.64

wasi-common < 1 Windows builds broken

I would have to bump everything to ^1 atm from 0.40

Root cause

This was seen earlier in https://github.com/bytecodealliance/cap-std/issues/275 via nightly broken

A trait was sealed that then broke the builds via [cap-primitives](https://crates.io/crates/cap-primitives)

I documented my find originally: https://github.com/rust-lang/rust/issues/102260

Work/Around - Works for Windows Only probably ?

There is a work/around here: https://github.com/bytecodealliance/wasmtime/issues/4936

The work/around patch is in cap-std commits:
git diff de739728299408dfce96315b3c82a14c952a6cf3 949f251bccbb84513fe81a427a46864c1e8ad82c

Work/Around does not work for unix

Work/around in turn seems to break unix builds as described here: https://github.com/bytecodealliance/wasmtime/issues/4936#issuecomment-1257183650

Ideal Resolution ?

Could we address so this builds for both Windows and Linux / unix via 0.40 ?

Perhaps we could also bump wasi-common so it bumps up to 0.26 that whole chain for cap-primitives ?

But I think the build errors need to be sorted for unix as I suspect the patch has broken all unix now ? https://github.com/bytecodealliance/wasmtime/issues/4936#issuecomment-1257183650

This is how I bumped my :lock: to 0.40.1 - released 25 days ago or so

Additional attempts

I also tried quickly with 0.40.1 wasi-common but it still brings 0.25 tree

$ cargo update -p wasmtime-wasi --precise 0.40.1

    Updating crates.io index
    Updating cranelift-bforest v0.87.0 -> v0.87.1
    Updating cranelift-codegen v0.87.0 -> v0.87.1
    Updating cranelift-codegen-meta v0.87.0 -> v0.87.1
    Updating cranelift-codegen-shared v0.87.0 -> v0.87.1
    Updating cranelift-entity v0.87.0 -> v0.87.1
    Updating cranelift-frontend v0.87.0 -> v0.87.1
    Updating cranelift-isle v0.87.0 -> v0.87.1
    Updating cranelift-native v0.87.0 -> v0.87.1
    Updating cranelift-wasm v0.87.0 -> v0.87.1
    Updating wasi-cap-std-sync v0.40.0 -> v0.40.1
    Updating wasi-common v0.40.0 -> v0.40.1
    Updating wasmtime v0.40.0 -> v0.40.1
    Updating wasmtime-asm-macros v0.40.0 -> v0.40.1
    Updating wasmtime-cache v0.40.0 -> v0.40.1
    Updating wasmtime-cranelift v0.40.0 -> v0.40.1
    Updating wasmtime-environ v0.40.0 -> v0.40.1
    Updating wasmtime-fiber v0.40.0 -> v0.40.1
    Updating wasmtime-jit v0.40.0 -> v0.40.1
    Updating wasmtime-jit-debug v0.40.0 -> v0.40.1
    Updating wasmtime-runtime v0.40.0 -> v0.40.1
    Updating wasmtime-types v0.40.0 -> v0.40.1
    Updating wasmtime-wasi v0.40.0 -> v0.40.1
    Updating wiggle v0.40.0 -> v0.40.1
    Updating wiggle-generate v0.40.0 -> v0.40.1
    Updating wiggle-macro v0.40.0 -> v0.40.1

And my dependency tree gets 0.25 on which I had to apply the branch-patch

         ├── wasi-common v0.40.1
            ├── cap-rand v0.25.2
            ├── cap-std v0.25.3
               ├── cap-primitives v0.25.3

I originally went down the :hole: https://github.com/bytecodealliance/cap-std/issues/270#issuecomment-1257176470

Refs

https://github.com/lunatic-solutions/lunatic/issues/136 <-- Downstream crate impacted
https://github.com/rust-lang/rust/issues/102260 <-- Went finding out what happened in std first - did not find these issues here
https://github.com/bytecodealliance/cap-std/issues/275 <-- I went first
https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/.E2.9C.94.20.23102260.20Sealed.20Windows.20FileTypeExt/near/300637075 <-- Chris Denton was helpful to point the above issue

Cheers

view this post on Zulip Wasmtime GitHub notifications bot (Sep 25 2022 at 14:20):

sunfishcode commented on issue #4957:

Please include the error message in this report.

view this post on Zulip Wasmtime GitHub notifications bot (Sep 25 2022 at 14:25):

sunfishcode commented on issue #4957:

I've now created a new branch:
https://github.com/bytecodealliance/cap-std/tree/0.26-with-a-0.25.2-version-number

It is identical to the previous branch, except it sets the version number to 0.25.2, which may help with the cargo patch mechanism.

view this post on Zulip Wasmtime GitHub notifications bot (Sep 25 2022 at 14:26):

pinkforest commented on issue #4957:

This was via 0.40 - unadulterated with no patching applied - on today's 1.64 stable as well as latest nightly (1.66.0-nightly (https://github.com/rust-lang/rust/commit/4a14677239bbd9a3892d165ee24513c1a05820e4 2022-09-23) on Windows

From: https://github.com/lunatic-solutions/lunatic/issues/136

 error[E0277]: the trait bound file_type::FileType: std::sealed::Sealed is not satisfied
    <snip>
        |
    134 | impl std::os::windows::fs::FileTypeExt for FileType {
        |      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait std::sealed::Sealed is not implemented for file_type::FileType
        |
    <snip>
    error: could not compile cap-primitives due to previous error
    warning: build failed, waiting for other jobs to finish...
    error: failed to compile lunatic-runtime v0.10.0, intermediate artifacts can be found at <snip>

When I tried patching work/around I get the mix-up

view this post on Zulip Wasmtime GitHub notifications bot (Sep 25 2022 at 14:31):

pinkforest commented on issue #4957:

Okay I now was properly able to patch all three crates and works in unix

I will get this work/around tested in Windows now

view this post on Zulip Wasmtime GitHub notifications bot (Sep 25 2022 at 14:32):

pinkforest edited a comment on issue #4957:

Okay I now was properly able to patch all three crates and works in unix w/ 0.26-with-a-0.25.2-version-number branch

I will get this work/around tested in Windows now

This is my root Cargo.toml to patch it

##########################################################
# This is required until wasmtime is bumped to ^1
# https://github.com/bytecodealliance/wasmtime/issues/4957
# Tracking: https://github.com/lunatic-solutions/lunatic/issues/136
[patch.crates-io]
cap-std = { git = "https://github.com/bytecodealliance/cap-std.git", branch = "0.26-with-a-0.25.2-version-number" }
cap-primitives = { git = "https://github.com/bytecodealliance/cap-std.git", branch = "0.26-with-a-0.25.2-version-number" }
cap-fs-ext = { git = "https://github.com/bytecodealliance/cap-std.git", branch = "0.26-with-a-0.25.2-version-number" }

view this post on Zulip Wasmtime GitHub notifications bot (Sep 25 2022 at 14:32):

pinkforest edited a comment on issue #4957:

Okay I now was properly able to patch all three crates and builds in unix w/ 0.26-with-a-0.25.2-version-number branch

I will get this work/around tested in Windows now

This is my root Cargo.toml to patch it

##########################################################
# This is required until wasmtime is bumped to ^1
# https://github.com/bytecodealliance/wasmtime/issues/4957
# Tracking: https://github.com/lunatic-solutions/lunatic/issues/136
[patch.crates-io]
cap-std = { git = "https://github.com/bytecodealliance/cap-std.git", branch = "0.26-with-a-0.25.2-version-number" }
cap-primitives = { git = "https://github.com/bytecodealliance/cap-std.git", branch = "0.26-with-a-0.25.2-version-number" }
cap-fs-ext = { git = "https://github.com/bytecodealliance/cap-std.git", branch = "0.26-with-a-0.25.2-version-number" }

view this post on Zulip Wasmtime GitHub notifications bot (Sep 25 2022 at 14:33):

pinkforest edited a comment on issue #4957:

Okay I now was properly able to patch all three crates and builds in unix w/ 0.26-with-a-0.25.2-version-number branch

I will get this work/around tested in Windows now

This is my root Cargo.toml to patch it

##########################################################
# This is required until wasmtime is bumped to ^1
# https://github.com/bytecodealliance/wasmtime/issues/4957
# Tracking: https://github.com/lunatic-solutions/lunatic/issues/136
[patch.crates-io]
cap-std = { git = "https://github.com/bytecodealliance/cap-std.git", branch = "0.26-with-a-0.25.2-version-number" }
cap-primitives = { git = "https://github.com/bytecodealliance/cap-std.git", branch = "0.26-with-a-0.25.2-version-number" }
cap-fs-ext = { git = "https://github.com/bytecodealliance/cap-std.git", branch = "0.26-with-a-0.25.2-version-number" }

This was with:

active toolchain
----------------

stable-x86_64-unknown-linux-gnu (default)
rustc 1.64.0 (a55dd71d5 2022-09-19)

view this post on Zulip Wasmtime GitHub notifications bot (Sep 25 2022 at 14:37):

sunfishcode commented on issue #4957:

This was via 0.40 - unadulterated with no patching applied - on today's 1.64 stable as well as latest nightly (1.66.0-nightly (https://github.com/rust-lang/rust/commit/4a14677239bbd9a3892d165ee24513c1a05820e4 2022-09-23) on Windows

the trait bound file_type::FileType: std::sealed::Sealed is not satisfied

I'm unable to reproduce this error on Windows with wasi-common 0.40 and today's 1.64 stable.

I do see it with Rust nightly-2022-09-23. This is a known problem, and the fix is https://github.com/bytecodealliance/wasmtime/pull/4940.

view this post on Zulip Wasmtime GitHub notifications bot (Sep 25 2022 at 14:42):

pinkforest commented on issue #4957:

Strange, we'll need to in any case use this patch-branch given we are unable to get 0.26 cap-std via 0.40 and it's in nightly at least

Thanks for providing the branch, we'll try to bump to ^1 asap

view this post on Zulip Wasmtime GitHub notifications bot (Sep 25 2022 at 14:43):

pinkforest closed issue #4957:

Problem now is that anyone using 0.40 e.g. via wasi-common will get 0.25 cap-std

         ├── wasi-common v0.40.0
            ├── cap-rand v0.25.2
            ├── cap-std v0.25.2
               ├── cap-primitives v0.25.2

And therefore incompat cap-primitives in Windows when using stable > 1.64.0 rust stable that has sealed the FileTypeExt trait

By doing nothing this still works on at least unix but Windows is now broken on it's default state doing nothing on rust stable 1.64

wasi-common < 1 Windows builds broken

I would have to bump everything to ^1 atm from 0.40

Root cause

This was seen earlier in https://github.com/bytecodealliance/cap-std/issues/275 via nightly broken

A trait was sealed that then broke the builds via [cap-primitives](https://crates.io/crates/cap-primitives)

I documented my find originally: https://github.com/rust-lang/rust/issues/102260

Work/Around - Works for Windows Only probably ?

There is a work/around here: https://github.com/bytecodealliance/wasmtime/issues/4936

The work/around patch is in cap-std commits:
git diff de739728299408dfce96315b3c82a14c952a6cf3 949f251bccbb84513fe81a427a46864c1e8ad82c

Work/Around does not work for unix

Work/around in turn seems to break unix builds as described here: https://github.com/bytecodealliance/wasmtime/issues/4936#issuecomment-1257183650

Ideal Resolution ?

Could we address so this builds for both Windows and Linux / unix via 0.40 ?

Perhaps we could also bump wasi-common so it bumps up to 0.26 that whole chain for cap-primitives ?

But I think the build errors need to be sorted for unix as I suspect the patch has broken all unix now ? https://github.com/bytecodealliance/wasmtime/issues/4936#issuecomment-1257183650

This is how I bumped my :lock: to 0.40.1 - released 25 days ago or so

Additional attempts

I also tried quickly with 0.40.1 wasi-common but it still brings 0.25 tree

$ cargo update -p wasmtime-wasi --precise 0.40.1

    Updating crates.io index
    Updating cranelift-bforest v0.87.0 -> v0.87.1
    Updating cranelift-codegen v0.87.0 -> v0.87.1
    Updating cranelift-codegen-meta v0.87.0 -> v0.87.1
    Updating cranelift-codegen-shared v0.87.0 -> v0.87.1
    Updating cranelift-entity v0.87.0 -> v0.87.1
    Updating cranelift-frontend v0.87.0 -> v0.87.1
    Updating cranelift-isle v0.87.0 -> v0.87.1
    Updating cranelift-native v0.87.0 -> v0.87.1
    Updating cranelift-wasm v0.87.0 -> v0.87.1
    Updating wasi-cap-std-sync v0.40.0 -> v0.40.1
    Updating wasi-common v0.40.0 -> v0.40.1
    Updating wasmtime v0.40.0 -> v0.40.1
    Updating wasmtime-asm-macros v0.40.0 -> v0.40.1
    Updating wasmtime-cache v0.40.0 -> v0.40.1
    Updating wasmtime-cranelift v0.40.0 -> v0.40.1
    Updating wasmtime-environ v0.40.0 -> v0.40.1
    Updating wasmtime-fiber v0.40.0 -> v0.40.1
    Updating wasmtime-jit v0.40.0 -> v0.40.1
    Updating wasmtime-jit-debug v0.40.0 -> v0.40.1
    Updating wasmtime-runtime v0.40.0 -> v0.40.1
    Updating wasmtime-types v0.40.0 -> v0.40.1
    Updating wasmtime-wasi v0.40.0 -> v0.40.1
    Updating wiggle v0.40.0 -> v0.40.1
    Updating wiggle-generate v0.40.0 -> v0.40.1
    Updating wiggle-macro v0.40.0 -> v0.40.1

And my dependency tree gets 0.25 on which I had to apply the branch-patch

         ├── wasi-common v0.40.1
            ├── cap-rand v0.25.2
            ├── cap-std v0.25.3
               ├── cap-primitives v0.25.3

I originally went down the :hole: https://github.com/bytecodealliance/cap-std/issues/270#issuecomment-1257176470

Refs

https://github.com/lunatic-solutions/lunatic/issues/136 <-- Downstream crate impacted
https://github.com/rust-lang/rust/issues/102260 <-- Went finding out what happened in std first - did not find these issues here
https://github.com/bytecodealliance/cap-std/issues/275 <-- I went first
https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/.E2.9C.94.20.23102260.20Sealed.20Windows.20FileTypeExt/near/300637075 <-- Chris Denton was helpful to point the above issue

Cheers

view this post on Zulip Wasmtime GitHub notifications bot (Sep 25 2022 at 14:44):

pinkforest commented on issue #4957:

(I am assuming that patch-branch will stay there for a while so we can bump to ^1 meanwhile)

view this post on Zulip Wasmtime GitHub notifications bot (Sep 25 2022 at 14:44):

pinkforest deleted a comment on issue #4957:

(I am assuming that patch-branch will stay there for a while so we can bump to ^1 meanwhile)

view this post on Zulip Wasmtime GitHub notifications bot (Sep 25 2022 at 14:44):

pinkforest edited a comment on issue #4957:

Strange, we'll need to in any case use this patch-branch given we are unable to get 0.26 cap-std via 0.40 and it's in nightly at least

Thanks for providing the branch, we'll try to bump to ^1 asap

I'll close this since I do not expect to find anymore issues - thanks a lot!

(I am assuming that patch-branch will stay there for a while so we can bump to ^1 meanwhile)

view this post on Zulip Wasmtime GitHub notifications bot (Sep 25 2022 at 15:15):

pinkforest commented on issue #4957:

I'm unable to reproduce this error on Windows with wasi-common 0.40 and today's 1.64 stable.
I do see it with Rust nightly-2022-09-23. This is a known problem, and the fix is https://github.com/bytecodealliance/wasmtime/pull/4940.

The stabilisation happened here: https://github.com/rust-lang/rust/pull/98583/files which led to the Sealed error

It should re-produce in 1.64 going by that in 0.40 without the patch to deal with the Sealed change that came along ....

Not sure why it is not re-producing ?

view this post on Zulip Wasmtime GitHub notifications bot (Sep 25 2022 at 15:15):

pinkforest edited a comment on issue #4957:

I'm unable to reproduce this error on Windows with wasi-common 0.40 and today's 1.64 stable.
I do see it with Rust nightly-2022-09-23. This is a known problem, and the fix is https://github.com/bytecodealliance/wasmtime/pull/4940.

The stabilisation happened here: https://github.com/rust-lang/rust/pull/98583/files which led to the Sealed error

It should re-produce in 1.64.0 stable going by that via 0.40 without the patch to deal with the Sealed change that came along ....

Not sure why it is not re-producing ?

view this post on Zulip Wasmtime GitHub notifications bot (Sep 25 2022 at 15:15):

pinkforest edited a comment on issue #4957:

I'm unable to reproduce this error on Windows with wasi-common 0.40 and today's 1.64 stable.
I do see it with Rust nightly-2022-09-23. This is a known problem, and the fix is https://github.com/bytecodealliance/wasmtime/pull/4940.

The stabilisation happened here: https://github.com/rust-lang/rust/pull/98583/files which led to the Sealed error

It should re-produce in 1.64.0 stable going by that via 0.40 without the patch to deal with the Sealed change that came along ....

Not sure why it is not re-producing in 1.64.0 stable ?

view this post on Zulip Wasmtime GitHub notifications bot (Sep 25 2022 at 15:16):

pinkforest edited a comment on issue #4957:

I'm unable to reproduce this error on Windows with wasi-common 0.40 and today's 1.64 stable.
I do see it with Rust nightly-2022-09-23. This is a known problem, and the fix is https://github.com/bytecodealliance/wasmtime/pull/4940.

The stabilisation happened here: https://github.com/rust-lang/rust/pull/98583/files which led to the Sealed error

It should re-produce in 1.64.0 stable going by that via 0.40 without the patch to deal with the Sealed change that came along ....

Not sure why it is not re-producing in 1.64.0 stable on your side ?

view this post on Zulip Wasmtime GitHub notifications bot (Sep 25 2022 at 15:16):

pinkforest edited a comment on issue #4957:

I'm unable to reproduce this error on Windows with wasi-common 0.40 and today's 1.64 stable.
I do see it with Rust nightly-2022-09-23. This is a known problem, and the fix is https://github.com/bytecodealliance/wasmtime/pull/4940.

The stabilisation happened here: https://github.com/rust-lang/rust/pull/98583 which led to the Sealed error

The Sealing itself is on 2nd commit

It should re-produce in 1.64.0 stable going by that via 0.40 without the patch to deal with the Sealed change that came along ....

Not sure why it is not re-producing in 1.64.0 stable on your side ?

view this post on Zulip Wasmtime GitHub notifications bot (Sep 25 2022 at 15:53):

pinkforest edited a comment on issue #4957:

I'm unable to reproduce this error on Windows with wasi-common 0.40 and today's 1.64 stable.
I do see it with Rust nightly-2022-09-23. This is a known problem, and the fix is https://github.com/bytecodealliance/wasmtime/pull/4940.

The stabilisation happened here: https://github.com/rust-lang/rust/pull/98583 which led to the Sealed error

The Sealing itself is on 2nd commit

It should re-produce in 1.64.0 stable going by that via 0.40 without the patch to deal with the Sealed change that came along ....

Not sure why it is not re-producing in 1.64.0 stable on your side ?

So std::os::windows::fs::FileTypeExt was previously placeholders in here .. 1.64.0 just happened to land it and with Sealed

This is what I could derive from rename of std::os::unix::fs::FileTypeExt in here:
git diff de739728299408dfce96315b3c82a14c952a6cf3 949f251bccbb84513fe81a427a46864c1e8ad82c

The 1.64 and nightlies before and after that have that so current 1.64 stable is as stable was broken before ?

view this post on Zulip Wasmtime GitHub notifications bot (Sep 25 2022 at 15:53):

pinkforest edited a comment on issue #4957:

I'm unable to reproduce this error on Windows with wasi-common 0.40 and today's 1.64 stable.
I do see it with Rust nightly-2022-09-23. This is a known problem, and the fix is https://github.com/bytecodealliance/wasmtime/pull/4940.

The stabilisation happened here: https://github.com/rust-lang/rust/pull/98583 which led to the Sealed error

The Sealing itself is on 2nd commit

It should re-produce in 1.64.0 stable going by that via 0.40 without the patch to deal with the Sealed change that came along ....

Not sure why it is not re-producing in 1.64.0 stable on your side ?

So std::os::windows::fs::FileTypeExt was previously placeholders in here .. 1.64.0 just happened to land it and with Sealed

This is what I could derive from rename of std::os::unix::fs::FileTypeExt in here:
git diff de739728299408dfce96315b3c82a14c952a6cf3 949f251bccbb84513fe81a427a46864c1e8ad82c

The 1.64 stable and nightlies before and after should be broken due to result of this stabilisation.

view this post on Zulip Wasmtime GitHub notifications bot (Sep 25 2022 at 15:54):

pinkforest edited a comment on issue #4957:

I'm unable to reproduce this error on Windows with wasi-common 0.40 and today's 1.64 stable.
I do see it with Rust nightly-2022-09-23. This is a known problem, and the fix is https://github.com/bytecodealliance/wasmtime/pull/4940.

The stabilisation happened here: https://github.com/rust-lang/rust/pull/98583 which led to the Sealed error

The Sealing itself is on 2nd commit

It should re-produce in 1.64.0 stable going by that via 0.40 without the patch to deal with the Sealed change that came along ....

Not sure why it is not re-producing in 1.64.0 stable on your side ?

So std::os::windows::fs::FileTypeExt was previously placeholders in here .. 1.64.0 just happened to land it and with Sealed

This is what I could derive from rename of std::os::unix::fs::FileTypeExt in here:
git diff de739728299408dfce96315b3c82a14c952a6cf3 949f251bccbb84513fe81a427a46864c1e8ad82c

The 1.64 stable and nightlies before and after should be broken due to result of this stabilisation that included the Sealed

view this post on Zulip Wasmtime GitHub notifications bot (Sep 25 2022 at 16:23):

pinkforest edited a comment on issue #4957:

I'm unable to reproduce this error on Windows with wasi-common 0.40 and today's 1.64 stable.
I do see it with Rust nightly-2022-09-23. This is a known problem, and the fix is https://github.com/bytecodealliance/wasmtime/pull/4940.

The stabilisation happened here: https://github.com/rust-lang/rust/pull/98583 which led to the Sealed error

The Sealing itself is on 2nd commit

It should re-produce in 1.64.0 stable going by that via 0.40 without the patch to deal with the Sealed change that came along ....

Not sure why it is not re-producing in 1.64.0 stable on your side ?

So std::os::windows::fs::FileTypeExt was previously placeholders in here .. 1.64.0 just happened to land it and with Sealed

This is what I could derive from eventual cloning of std::os::unix::fs::FileTypeExt in here:
git diff de739728299408dfce96315b3c82a14c952a6cf3 949f251bccbb84513fe81a427a46864c1e8ad82c

The 1.64 stable and nightlies before and after should be broken due to result of this stabilisation that included the Sealed

view this post on Zulip Wasmtime GitHub notifications bot (Sep 25 2022 at 16:25):

pinkforest edited a comment on issue #4957:

I'm unable to reproduce this error on Windows with wasi-common 0.40 and today's 1.64 stable.
I do see it with Rust nightly-2022-09-23. This is a known problem, and the fix is https://github.com/bytecodealliance/wasmtime/pull/4940.

The stabilisation happened here: https://github.com/rust-lang/rust/pull/98583 which led to that Sealed error

The Sealing itself is on 2nd commit which then broke the impl that was relying on the FileTypeExt trait behind unstable feature -

It should re-produce in 1.64.0 stable going by that via 0.40 without the patch to deal with the Sealed change that came along ....

Not sure why it is not re-producing in 1.64.0 stable on your side ?

So std::os::windows::fs::FileTypeExt was previously placeholders in here .. 1.64.0 just happened to land it and with Sealed

This is what I could derive from eventual cloning of std::os::unix::fs::FileTypeExt in here:
git diff de739728299408dfce96315b3c82a14c952a6cf3 949f251bccbb84513fe81a427a46864c1e8ad82c

The 1.64 stable and nightlies before and after should be broken due to result of this stabilisation that included the Sealed

view this post on Zulip Wasmtime GitHub notifications bot (Sep 25 2022 at 16:25):

pinkforest edited a comment on issue #4957:

I'm unable to reproduce this error on Windows with wasi-common 0.40 and today's 1.64 stable.
I do see it with Rust nightly-2022-09-23. This is a known problem, and the fix is https://github.com/bytecodealliance/wasmtime/pull/4940.

The stabilisation happened here: https://github.com/rust-lang/rust/pull/98583 which led to that Sealed error

The Sealing itself is on 2nd commit which then broke the impl that was relying on the FileTypeExt trait behind unstable feature

It should re-produce in 1.64.0 stable going by that via 0.40 without the patch to deal with the Sealed change that came along ....

Not sure why it is not re-producing in 1.64.0 stable on your side ?

So std::os::windows::fs::FileTypeExt was previously placeholders in here .. 1.64.0 just happened to land it and with Sealed

This is what I could derive from eventual cloning of std::os::unix::fs::FileTypeExt in here:
git diff de739728299408dfce96315b3c82a14c952a6cf3 949f251bccbb84513fe81a427a46864c1e8ad82c

The 1.64 stable and nightlies before and after should be broken due to result of this stabilisation that included the Sealed

view this post on Zulip Wasmtime GitHub notifications bot (Sep 25 2022 at 17:59):

sunfishcode commented on issue #4957:

This repo: https://github.com/sunfishcode/wasi-common-test

depends on wasi-common 0.40 and builds for me on Rust 1.64.0 on Windows. Does it fail for you?

If not, could you prepare a repository which shows the failure?

view this post on Zulip Wasmtime GitHub notifications bot (Sep 25 2022 at 18:48):

pinkforest commented on issue #4957:

Having difficulties atm sourcing a working wine or windows instance to do further testing.

We had it in cargo install lunatic-runtime which is not exactly Minimally Reproducible Example but the released crate (via install) reflects v0.10.0 tag in the repo here: https://github.com/lunatic-solutions/lunatic/releases/tag/v0.10.0

Chris may be right here that this may have been also a red herring with Sealed and the real issue where nightly is somehow other way impacted that wasn't relayed via 1.64.0 necessarily -

Question is if 1.64.0 is not really impacted - given re-testing - then this may or may not stabilise later besides windows_file_type_ext that I was looking at from both the patch and the stabilisation PoV considering the rather clear error suspect causation... it would be nice to find an answer to this..

Will be curious to find out once I get my Windows back ..

view this post on Zulip Wasmtime GitHub notifications bot (Sep 25 2022 at 18:51):

pinkforest edited a comment on issue #4957:

Having difficulties atm sourcing a working wine or windows instance to do further testing.

We had it in cargo install lunatic-runtime which is not exactly Minimally Reproducible Example but the released crate (via install) reflects v0.10.0 tag in the repo here: https://github.com/lunatic-solutions/lunatic/releases/tag/v0.10.0

Chris may be right here that this may have been also a red herring with Sealed and the real issue where nightly is somehow other way impacted that wasn't relayed via 1.64.0 necessarily as one would expect from: https://github.com/rust-lang/rust/pull/98583/files

Question is if 1.64.0 is not really impacted - given re-testing - then this may or may not stabilise later besides windows_file_type_ext that I was looking at from both the patch and the stabilisation PoV considering the rather clear error suspect causation... it would be nice to find an answer to this..

Will be curious to find out once I get my Windows back ..

view this post on Zulip Wasmtime GitHub notifications bot (Sep 25 2022 at 18:52):

pinkforest edited a comment on issue #4957:

Having difficulties atm sourcing a working wine or windows instance to do further testing.

We had it in cargo install lunatic-runtime which is not exactly Minimally Reproducible Example but the released crate (via install) reflects v0.10.0 tag in the repo here: https://github.com/lunatic-solutions/lunatic/releases/tag/v0.10.0

Chris may be right here that this may have been also a red herring with Sealed and the real issue where nightly is somehow other way impacted that wasn't relayed via 1.64.0 necessarily as one would expect from: https://github.com/rust-lang/rust/pull/98583/files

Question is if 1.64.0 is not really impacted - given re-testing - then this may or may not stabilise later besides windows_file_type_ext that I was looking at from both the patch and the stabilisation PoV considering the obvious error suspect causation and stabilisation around it... it would be nice to find an answer to this..

Will be curious to find out once I get my Windows back ..

view this post on Zulip Wasmtime GitHub notifications bot (Sep 25 2022 at 18:53):

pinkforest edited a comment on issue #4957:

Having difficulties atm sourcing a working wine or windows instance to do further testing.

We had it in cargo install lunatic-runtime which is not exactly Minimally Reproducible Example but the released crate (via install) reflects v0.10.0 tag in the repo here: https://github.com/lunatic-solutions/lunatic/releases/tag/v0.10.0

Chris may be right here that this may have been also a red herring with Sealed and the real issue where nightly is somehow other way impacted that wasn't relayed via 1.64.0 necessarily as one would expect from: https://github.com/rust-lang/rust/pull/98583/files

Question is if 1.64.0 is not really impacted - given re-testing - then this may or may not stabilise later besides windows_file_type_ext that I was looking at.. it would be nice to find an answer to this..

Will be curious to find out once I get my Windows back ..

view this post on Zulip Wasmtime GitHub notifications bot (Sep 25 2022 at 20:07):

pinkforest commented on issue #4957:

Okay I did extensive further regression on this and it seems 1.64 stable is working still.

The Sealed stuff was red herring indeed -

Now further off to look for that regression what what causes it with the nightly ... purely off curiosity ofcourse

But for the time being the branch fix is sufficient - thank you :heart:

view this post on Zulip Wasmtime GitHub notifications bot (Sep 25 2022 at 20:10):

pinkforest commented on issue #4957:

btw fwiw - without fix applied today's nightly still continues this regression w/o the patch branch applied -

Default host: x86_64-pc-windows-msvc

installed toolchains
--------------------

stable-x86_64-pc-windows-msvc
nightly-x86_64-pc-windows-msvc (default)

active toolchain
----------------

nightly-x86_64-pc-windows-msvc (default)
rustc 1.66.0-nightly (3f83906b3 2022-09-24)

   Compiling wast v35.0.2
error[E0277]: the trait bound `file_type::FileType: std::sealed::Sealed` is not satisfied
   --> C:\..\.cargo\registry\src\github.com-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`

For more information about this error, try `rustc --explain E0277`.
error: could not compile `cap-primitives` due to previous error
warning: build failed, waiting for other jobs to finish...
error: failed to compile `lunatic-runtime v0.10.0`, intermediate artifacts can be found at `C:\..\AppData\Local\Temp\cargo-installBWk9L0`

view this post on Zulip Wasmtime GitHub notifications bot (Sep 25 2022 at 20:24):

pinkforest edited a comment on issue #4957:

btw fwiw - without fix applied today's nightly still continues this regression w/o the patch branch applied -

_So let me guess nightly simply regresses because Sealed is perma-unstable and sealed itself would not get enabled as feature in stable Rust where as in nightly the perma-unstable feature operates in_

Hmm :thinking: yeah it's 6:23 AM going to sleep

Default host: x86_64-pc-windows-msvc

installed toolchains
--------------------

stable-x86_64-pc-windows-msvc
nightly-x86_64-pc-windows-msvc (default)

active toolchain
----------------

nightly-x86_64-pc-windows-msvc (default)
rustc 1.66.0-nightly (3f83906b3 2022-09-24)

   Compiling wast v35.0.2
error[E0277]: the trait bound `file_type::FileType: std::sealed::Sealed` is not satisfied
   --> C:\..\.cargo\registry\src\github.com-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`

For more information about this error, try `rustc --explain E0277`.
error: could not compile `cap-primitives` due to previous error
warning: build failed, waiting for other jobs to finish...
error: failed to compile `lunatic-runtime v0.10.0`, intermediate artifacts can be found at `C:\..\AppData\Local\Temp\cargo-installBWk9L0`

view this post on Zulip Wasmtime GitHub notifications bot (Sep 25 2022 at 20:24):

pinkforest edited a comment on issue #4957:

btw fwiw - without fix applied today's nightly still continues this regression w/o the patch branch applied -

_So let me guess nightly simply regresses because Sealed is perma-unstable and sealed itself would not get enabled as a feature in stable Rust where as in nightly the perma-unstable feature operates in_

Hmm :thinking: yeah it's 6:23 AM going to sleep

Default host: x86_64-pc-windows-msvc

installed toolchains
--------------------

stable-x86_64-pc-windows-msvc
nightly-x86_64-pc-windows-msvc (default)

active toolchain
----------------

nightly-x86_64-pc-windows-msvc (default)
rustc 1.66.0-nightly (3f83906b3 2022-09-24)

   Compiling wast v35.0.2
error[E0277]: the trait bound `file_type::FileType: std::sealed::Sealed` is not satisfied
   --> C:\..\.cargo\registry\src\github.com-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`

For more information about this error, try `rustc --explain E0277`.
error: could not compile `cap-primitives` due to previous error
warning: build failed, waiting for other jobs to finish...
error: failed to compile `lunatic-runtime v0.10.0`, intermediate artifacts can be found at `C:\..\AppData\Local\Temp\cargo-installBWk9L0`

view this post on Zulip Wasmtime GitHub notifications bot (Sep 25 2022 at 20:24):

pinkforest edited a comment on issue #4957:

btw fwiw - without fix applied today's nightly still continues this regression w/o the patch branch applied -

_So let me guess nightly simply regresses because Sealed is perma-unstable and sealed itself would not get enabled as a feature in stable Rust where as in nightly the perma-unstable feature operates solely in_

Hmm :thinking: yeah it's 6:23 AM going to sleep

Default host: x86_64-pc-windows-msvc

installed toolchains
--------------------

stable-x86_64-pc-windows-msvc
nightly-x86_64-pc-windows-msvc (default)

active toolchain
----------------

nightly-x86_64-pc-windows-msvc (default)
rustc 1.66.0-nightly (3f83906b3 2022-09-24)

   Compiling wast v35.0.2
error[E0277]: the trait bound `file_type::FileType: std::sealed::Sealed` is not satisfied
   --> C:\..\.cargo\registry\src\github.com-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`

For more information about this error, try `rustc --explain E0277`.
error: could not compile `cap-primitives` due to previous error
warning: build failed, waiting for other jobs to finish...
error: failed to compile `lunatic-runtime v0.10.0`, intermediate artifacts can be found at `C:\..\AppData\Local\Temp\cargo-installBWk9L0`

view this post on Zulip Wasmtime GitHub notifications bot (Sep 25 2022 at 20:24):

pinkforest deleted a comment on issue #4957:

btw fwiw - without fix applied today's nightly still continues this regression w/o the patch branch applied -

_So let me guess nightly simply regresses because Sealed is perma-unstable and sealed itself would not get enabled as a feature in stable Rust where as in nightly the perma-unstable feature operates solely in_

Hmm :thinking: yeah it's 6:23 AM going to sleep

Default host: x86_64-pc-windows-msvc

installed toolchains
--------------------

stable-x86_64-pc-windows-msvc
nightly-x86_64-pc-windows-msvc (default)

active toolchain
----------------

nightly-x86_64-pc-windows-msvc (default)
rustc 1.66.0-nightly (3f83906b3 2022-09-24)

   Compiling wast v35.0.2
error[E0277]: the trait bound `file_type::FileType: std::sealed::Sealed` is not satisfied
   --> C:\..\.cargo\registry\src\github.com-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`

For more information about this error, try `rustc --explain E0277`.
error: could not compile `cap-primitives` due to previous error
warning: build failed, waiting for other jobs to finish...
error: failed to compile `lunatic-runtime v0.10.0`, intermediate artifacts can be found at `C:\..\AppData\Local\Temp\cargo-installBWk9L0`

view this post on Zulip Wasmtime GitHub notifications bot (Sep 25 2022 at 20:25):

pinkforest edited a comment on issue #4957:

Okay I did extensive further regression on this and it seems 1.64 stable is working still.

The Sealed stuff was red herring indeed -

Now further off to look for that regression what what causes it with the nightly ... purely off curiosity ofcourse

But for the time being the branch fix is sufficient - thank you :heart:

FWIW - About nightly

btw fwiw - without fix applied today's nightly still continues this regression w/o the patch branch applied -

_So let me guess nightly simply regresses because Sealed is perma-unstable and sealed itself would not get enabled as a feature in stable Rust where as in nightly the perma-unstable feature operates solely in_

Hmm :thinking: yeah it's 6:23 AM going to sleep

Default host: x86_64-pc-windows-msvc

installed toolchains
--------------------

stable-x86_64-pc-windows-msvc
nightly-x86_64-pc-windows-msvc (default)

active toolchain
----------------

nightly-x86_64-pc-windows-msvc (default)
rustc 1.66.0-nightly (3f83906b3 2022-09-24)

   Compiling wast v35.0.2
error[E0277]: the trait bound `file_type::FileType: std::sealed::Sealed` is not satisfied
   --> C:\..\.cargo\registry\src\github.com-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`

For more information about this error, try `rustc --explain E0277`.
error: could not compile `cap-primitives` due to previous error
warning: build failed, waiting for other jobs to finish...
error: failed to compile `lunatic-runtime v0.10.0`, intermediate artifacts can be found at `C:\..\AppData\Local\Temp\cargo-installBWk9L0`

view this post on Zulip Wasmtime GitHub notifications bot (Sep 25 2022 at 20:25):

pinkforest deleted a comment on issue #4957:

Having difficulties atm sourcing a working wine or windows instance to do further testing.

We had it in cargo install lunatic-runtime which is not exactly Minimally Reproducible Example but the released crate (via install) reflects v0.10.0 tag in the repo here: https://github.com/lunatic-solutions/lunatic/releases/tag/v0.10.0

Chris may be right here that this may have been also a red herring with Sealed and the real issue where nightly is somehow other way impacted that wasn't relayed via 1.64.0 necessarily as one would expect from: https://github.com/rust-lang/rust/pull/98583/files

Question is if 1.64.0 is not really impacted - given re-testing - then this may or may not stabilise later besides windows_file_type_ext that I was looking at.. it would be nice to find an answer to this..

Will be curious to find out once I get my Windows back ..

view this post on Zulip Wasmtime GitHub notifications bot (Sep 25 2022 at 20:32):

pinkforest edited a comment on issue #4957:

Okay I did extensive further regression on this and it seems 1.64 stable is working still.

The Sealed stuff was red herring indeed -

Now further off to look for that regression what what causes it with the nightly ... purely off curiosity ofcourse

But for the time being the branch fix is sufficient - thank you :heart:

About nightly

btw fwiw - without fix applied today's nightly still continues this regression w/o the patch branch applied -

_So let me guess nightly simply regresses because Sealed is perma-unstable and sealed itself would not get enabled as a feature in stable Rust where as in nightly the perma-unstable feature operates solely in_

Hmm :thinking: yeah it's 6:23 AM going to sleep

Default host: x86_64-pc-windows-msvc

installed toolchains
--------------------

stable-x86_64-pc-windows-msvc
nightly-x86_64-pc-windows-msvc (default)

active toolchain
----------------

nightly-x86_64-pc-windows-msvc (default)
rustc 1.66.0-nightly (3f83906b3 2022-09-24)

   Compiling wast v35.0.2
error[E0277]: the trait bound `file_type::FileType: std::sealed::Sealed` is not satisfied
   --> C:\..\.cargo\registry\src\github.com-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`

For more information about this error, try `rustc --explain E0277`.
error: could not compile `cap-primitives` due to previous error
warning: build failed, waiting for other jobs to finish...
error: failed to compile `lunatic-runtime v0.10.0`, intermediate artifacts can be found at `C:\..\AppData\Local\Temp\cargo-installBWk9L0`

view this post on Zulip Wasmtime GitHub notifications bot (Sep 25 2022 at 20:33):

pinkforest edited a comment on issue #4957:

Okay I did extensive further regression on this and it seems 1.64 stable is working still.

The Sealed stuff was red herring indeed -

Now further off to look for that regression what what causes it with the nightly ... purely off curiosity ofcourse

But for the time being the branch fix is sufficient - thank you :heart:

About nightly

btw fwiw - without fix applied today's nightly still continues this regression w/o the patch branch applied -

_So let me guess nightly simply regresses because Sealed is perma-unstable and sealed itself would not get enabled as a feature in stable Rust where as in nightly the "perma-unstable" feature supposedly operates and is enabled by default solely in_

Hmm :thinking: yeah it's 6:23 AM going to sleep

Default host: x86_64-pc-windows-msvc

installed toolchains
--------------------

stable-x86_64-pc-windows-msvc
nightly-x86_64-pc-windows-msvc (default)

active toolchain
----------------

nightly-x86_64-pc-windows-msvc (default)
rustc 1.66.0-nightly (3f83906b3 2022-09-24)

   Compiling wast v35.0.2
error[E0277]: the trait bound `file_type::FileType: std::sealed::Sealed` is not satisfied
   --> C:\..\.cargo\registry\src\github.com-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`

For more information about this error, try `rustc --explain E0277`.
error: could not compile `cap-primitives` due to previous error
warning: build failed, waiting for other jobs to finish...
error: failed to compile `lunatic-runtime v0.10.0`, intermediate artifacts can be found at `C:\..\AppData\Local\Temp\cargo-installBWk9L0`


Last updated: Nov 22 2024 at 17:03 UTC