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
traitBy 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 ?
- [ ] 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 ? 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 issueCheers
sunfishcode commented on issue #4957:
Please include the error message in this report.
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-numberIt 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 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
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
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
branchI 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" }
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
branchI 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" }
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
branchI 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 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.
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
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
traitBy 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 ?
- [ ] 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 ? 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 issueCheers
pinkforest commented on issue #4957:
(I am assuming that patch-branch will stay there for a while so we can bump to ^1 meanwhile)
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)
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)
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 ?
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 ?
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 ?
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 ?
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 ?
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 SealedThis 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 ?
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 SealedThis 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.
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 SealedThis 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
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 SealedThis 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
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
errorThe
Sealing
itself is on 2nd commit which then broke the impl that was relying on theFileTypeExt
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 SealedThis 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
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
errorThe
Sealing
itself is on 2nd commit which then broke the impl that was relying on theFileTypeExt
trait behind unstable featureIt 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 SealedThis 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 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?
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) reflectsv0.10.0
tag in the repo here: https://github.com/lunatic-solutions/lunatic/releases/tag/v0.10.0Chris 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 ..
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) reflectsv0.10.0
tag in the repo here: https://github.com/lunatic-solutions/lunatic/releases/tag/v0.10.0Chris 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/filesQuestion 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 ..
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) reflectsv0.10.0
tag in the repo here: https://github.com/lunatic-solutions/lunatic/releases/tag/v0.10.0Chris 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/filesQuestion 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 ..
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) reflectsv0.10.0
tag in the repo here: https://github.com/lunatic-solutions/lunatic/releases/tag/v0.10.0Chris 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/filesQuestion 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 ..
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:
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`
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 andsealed
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`
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 andsealed
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`
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 andsealed
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`
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 andsealed
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`
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 andsealed
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`
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) reflectsv0.10.0
tag in the repo here: https://github.com/lunatic-solutions/lunatic/releases/tag/v0.10.0Chris 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/filesQuestion 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 ..
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 andsealed
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`
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 andsealed
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