Broken Windows builds via < 1 (or 0.40) since 1.64 stable #4957

pinkforest · 2022-09-25T12:57:43Z

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 bytecodealliance/cap-std#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: rust-lang/rust#102260

Work/Around - Works for Windows Only probably ?

There is a work/around here: #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: #4936 (comment)

Ideal Resolution ?

Avoid forcing ^1 bump via wasi-common from 0.40
Patch was broken on unix via patch-branch ?
Test patch on both Windows and Unix
Recursive point-release fix to 0.40 wasi-common -> cap-std 0.26 -> cap-primitives 0.26

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 ? #4936 (comment)

This is how I bumped my 🔒 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 🕳️ bytecodealliance/cap-std#270 (comment)

Refs

lunatic-solutions/lunatic#136 <-- Downstream crate impacted
rust-lang/rust#102260 <-- Went finding out what happened in std first - did not find these issues here
bytecodealliance/cap-std#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

The text was updated successfully, but these errors were encountered:

sunfishcode · 2022-09-25T14:20:04Z

Please include the error message in this report.

sunfishcode · 2022-09-25T14:25:55Z

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.

pinkforest · 2022-09-25T14:26:09Z

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 (rust-lang/rust@4a14677 2022-09-23) on Windows

From: lunatic-solutions/lunatic#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

pinkforest · 2022-09-25T14:31:10Z

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)

sunfishcode · 2022-09-25T14:37:17Z

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 (rust-lang/rust@4a14677 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 #4940.

pinkforest · 2022-09-25T14:42:08Z

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)

pinkforest · 2022-09-25T15:15:03Z

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 #4940.

The stabilisation happened here: rust-lang/rust#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

sunfishcode · 2022-09-25T17:59:35Z

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?

pinkforest · 2022-09-25T20:07:23Z

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 ❤️

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 🤔 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`

pinkforest changed the title ~~Broken Windows builds via wasi-common since 1.64.0 stable~~ Broken Windows builds via 0.4 wasi-common since 1.64.0 stable Sep 25, 2022

pinkforest changed the title ~~Broken Windows builds via 0.4 wasi-common since 1.64.0 stable~~ Broken Windows builds via 0.4 wasi-common since 1.64 stable Sep 25, 2022

pinkforest changed the title ~~Broken Windows builds via 0.4 wasi-common since 1.64 stable~~ Broken Windows builds via 0.4 since 1.64 stable Sep 25, 2022

pinkforest changed the title ~~Broken Windows builds via 0.4 since 1.64 stable~~ Broken Windows builds via 0.40 since 1.64 stable Sep 25, 2022

pinkforest changed the title ~~Broken Windows builds via 0.40 since 1.64 stable~~ Broken Windows builds via < 1 (or 0.40) since 1.64 stable Sep 25, 2022

pinkforest closed this as completed Sep 25, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Broken Windows builds via < 1 (or 0.40) since 1.64 stable #4957

Broken Windows builds via < 1 (or 0.40) since 1.64 stable #4957

pinkforest commented Sep 25, 2022 •

edited

Loading

sunfishcode commented Sep 25, 2022

sunfishcode commented Sep 25, 2022

pinkforest commented Sep 25, 2022

pinkforest commented Sep 25, 2022 •

edited

Loading

sunfishcode commented Sep 25, 2022

pinkforest commented Sep 25, 2022 •

edited

Loading

pinkforest commented Sep 25, 2022 •

edited

Loading

sunfishcode commented Sep 25, 2022

pinkforest commented Sep 25, 2022 •

edited

Loading

Broken Windows builds via < 1 (or 0.40) since 1.64 stable #4957

Broken Windows builds via < 1 (or 0.40) since 1.64 stable #4957

Comments

pinkforest commented Sep 25, 2022 • edited Loading

wasi-common < 1 Windows builds broken

Root cause

Work/Around - Works for Windows Only probably ?

Work/Around does not work for unix

Ideal Resolution ?

Additional attempts

Refs

sunfishcode commented Sep 25, 2022

sunfishcode commented Sep 25, 2022

pinkforest commented Sep 25, 2022

pinkforest commented Sep 25, 2022 • edited Loading

sunfishcode commented Sep 25, 2022

pinkforest commented Sep 25, 2022 • edited Loading

pinkforest commented Sep 25, 2022 • edited Loading

sunfishcode commented Sep 25, 2022

pinkforest commented Sep 25, 2022 • edited Loading

About nightly

pinkforest commented Sep 25, 2022 •

edited

Loading

pinkforest commented Sep 25, 2022 •

edited

Loading

pinkforest commented Sep 25, 2022 •

edited

Loading

pinkforest commented Sep 25, 2022 •

edited

Loading

pinkforest commented Sep 25, 2022 •

edited

Loading