Fails to build (wrong spirv version in spirq-core).
codecnotsupported opened this issue · comments
Not sure if it's just me but both git and stable crates.io versions fail to build.
Something to do with the version bump perhaps?
4fd4a8c#diff-4d4ad89fcc0c7ac2df009a3f9f955cd8d2e1c93f5c1e7211a4c0eb635275dc83R22
Build log
Nevermind, local issue.
Oddly enough purging cargo cache causes this issue to appear.
Setting spirq = "0" and then spirq = "*" fixes the issue.
Or not? Closing until I can reproduce reliably.
Managed to reliably reproduce.
Issue exists on new projects, tested on spirq = "1.1.1"
4fd4a8c#diff-4d4ad89fcc0c7ac2df009a3f9f955cd8d2e1c93f5c1e7211a4c0eb635275dc83R22
cargo tree
----cut----
└── spirq-core v1.0.3
├── anyhow v1.0.81
├── bytemuck v1.14.3
├── fnv v1.0.7
├── half v2.4.0
│ ├── cfg-if v1.0.0
│ └── num-traits v0.2.18 (*)
├── num-traits v0.2.18 (*)
├── ordered-float v3.9.2 (*)
└── spirv v0.3.0+sdk-1.3.268.0 <<<<<<<<<
└── bitflags v2.4.2
I can confirm this is actually happening.. Could you use the last release at the moment?
It's basically sourced from here. gfx-rs/rspirv#250 I'm trynna make a workaround for now but I'm looking forward to a more systematic solution real soon
I can confirm this is actually happening.. Could you use the last release at the moment?
Isn't 1.1.1 the latest release?
My current workaround is using git and specifying the revision before it broke spirq = {git="https://github.com/PENGUINLIONG/spirq-rs", rev="da5102ea6b43933dff4511db5d9751de68b482d5"}
This will do for now until #127 or/and gfx-rs/rspirv#250 is resolved.
No, I mean the one before that. Anyway, a fix is on the way. I figured out a way to workaround it in #131. Would you like to check if the PR actually fix both of the problems on your end?
It's on master now.
With the new impl I pinned to spirv >= 3.0. Just hope they don't make another breaking change next time. Closing now
Yep works on my end, thanks for the fix.
With the new impl I pinned to
spirv>= 3.0. Just hope they don't make another breaking change next time.
That's pretty dangerous and will break your spirq release whenever a breaking spirv crate is released with accompanying most-significant-version bump. That's exactly why semver exists and an unbounded >= shouldn't be used :)