wasm-bindgen no longer works with feature resolver version 1

[dtolnay]

$ cargo +stable new repro --edition=2018
$ cd repro
$ cargo +stable add wasm-bindgen@=0.2.96   # =0.2.95 works
$ cargo +stable check
...
error[E0554]: `#![feature]` may not be used on the stable release channel
 --> ~/.cargo/registry/src/index.crates.io-6f17d22bba15001f/wasm-bindgen-macro-0.2.96/src/lib.rs:4:5
  |
4 |     feature(allow_internal_unstable),
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
For more information about this error, try `rustc --explain E0554`.
error: could not compile `wasm-bindgen-macro` (lib) due to 1 previous error

$ rustc +stable --version --verbose
rustc 1.83.0 (90b35a623 2024-11-26)
binary: rustc
commit-hash: 90b35a6239c3d8bdabc530a6a0816f7ff89a0aaf
commit-date: 2024-11-26
host: x86_64-unknown-linux-gnu
release: 1.83.0
LLVM version: 19.1.1

[dtolnay]

Bisects to 83c9deb (#4284). @daxpedda

[daxpedda]

I added a CI check so this doesn't happen again.
Fixed in #4306.

[daxpedda]

So I had to dig into this a bit more, because apparently no [target.'cfg(...)'.dependencies] table worked correctly unless specifying the target. So that means no target_feature and no cfg flag. I found out that the issue can be solved by just using resolver = "2".

While I was working in #4306 to fix this issue without requiring resolver = "2", there are some interactions that can't be easily addressed and overall it makes the situation much worse. So I'm tending towards just requiring resolver = "2".

Any input would be appreciated!

[mxsrm]

You are breaking a lot of crates that depend on things like chrono (which depend on you), if the crates are using resolver version 1. Please revert the changes and publish a new hotfixed version that does not break ecosystemwide crates?

v0.2.97 is still affected:

❯ cargo build --release
warning: no edition set: defaulting to the 2015 edition while the latest is 2021
   Compiling wasm-bindgen-shared v0.2.97
   Compiling log v0.4.22
   Compiling bumpalo v3.16.0
   Compiling wasm-bindgen v0.2.97
   Compiling rav1e v0.7.1
   Compiling syn v2.0.90
   Compiling getrandom v0.2.15
   Compiling wasm-bindgen-backend v0.2.97
   Compiling thiserror-impl v1.0.69
   Compiling serde_derive v1.0.215
   Compiling profiling-procmacros v1.0.16
   Compiling arg_enum_proc_macro v0.3.4
   Compiling num-derive v0.4.2
   Compiling zerocopy-derive v0.7.35
   Compiling thiserror-impl v2.0.3
   Compiling displaydoc v0.2.5
   Compiling wasm-bindgen-macro-support v0.2.97
   Compiling profiling v1.0.16
   Compiling zerocopy v0.7.35
   Compiling thiserror v1.0.69
   Compiling pest v2.7.14
   Compiling wasm-bindgen-macro v0.2.97
error[E0554]: `#![feature]` may not be used on the stable release channel
 --> /home/max/.cargo/registry/src/index.crates.io-6f17d22bba15001f/wasm-bindgen-macro-0.2.97/src/lib.rs:4:5
  |
4 |     feature(allow_internal_unstable),
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

For more information about this error, try `rustc --explain E0554`.
error: could not compile `wasm-bindgen-macro` (lib) due to 1 previous error
warning: build failed, waiting for other jobs to finish...

[ozabalaferrera]

I'm not sure I fully understand what's going on here, but it seems like this is also the cause for this failed test/build:
https://github.com/cloudevents/sdk-rust/actions/runs/12123953925/job/33800591907
Does that seem right? Any updates on this issue?

[smoelius]

@ozabalaferrera When I change this line to edition = "2021", the problem goes away: https://github.com/cloudevents/sdk-rust/blob/09661ddaf72dfec2133962ae4dc6d322823558a1/Cargo.toml#L6

I think this is why: https://doc.rust-lang.org/edition-guide/rust-2021/default-cargo-resolver.html

[ozabalaferrera]

@smoelius, I don't think that worked for me. I also had tried setting resolver="2". here is the commit and test results: ozabalaferrera/cloudevents-sdk-rust@0972757

[daxpedda]

Edition upgrade is not necessary, it just requires resolver = "2".
I am planning to make some changes that just emit an error message saying exactly that.

I would really appreciate input on if people out there do still require resolver version 1.

[daxpedda]

In #4312 I added a clear error message saying the following:

error: Feature resolver version 2 or up is required.
       Please add `resolver = "2"` to your `Cargo.toml`.
       
       See <https://doc.rust-lang.org/1.83.0/cargo/reference/resolver.html#feature-resolver-version-2>.

[mxsrm]

If you introduce breaking changes, please follow semver and bump a major version.

[daxpedda]

If you introduce breaking changes, please follow semver and bump a major version.

The Rust ecosystem, which we are part of, doesn't follow Semver to the letter. We have certain policies that define what requires a minor/major version bump and what doesn't.

E.g. a project that doesn't have an MSRV policy, in my experience more than half the ecosystem, is free to upgrade its MSRV without a bump. Even though this is a breaking change.

While wasm-bindgen does have a MSRV policy, it doesn't have a feature resolver version policy.

If this doesn't fit your bill consider pinning your version dependency.

---

For context: we obviously try as much as we can not to introduce a breaking change, but unfortunately, some new features make this very hard to achieve. This wouldn't be a problem if we could simply bump the minor/major version, but this is not easily achieved with the wasm-bindgen project.

Unfortunately it is impossible to use a project depending on different versions of wasm-bindgen, so any semver bump will block the entire ecosystem until all dependencies are in sync. While this is obviously possible, it incurs an incredibly high cost and we can only do this as a last resort.

My hope is that in the future we can move on to only minimally require the post-processor, in which case multiple versions in the same compilation could be supported and semver bumps become low cost.

[mxsrm]

If this doesn't fit your bill consider pinning your version dependency.

I will never personally use wasm.

I will try to argue with the authors of chrono with > 220 million downloads to version pin your crate so they don't brake thousands of projects depending on wasm (whatever for) because you don't want to follow semver. Alternatively remove the dependency completely would probably be preferably.

[daxpedda]

This issue has been resolved in #4327 and wasm-bindgen is once again compatible with the feature resolver version 1. I also added a test so this doesn't regress again.

A new release with this fix is being cut right now, see #4330.

[jkelleyrtp]

Pinning the version is tough - we advise users to specify the exact version of wasm-bindgen and even wrote tooling to manually force the upgrade/downgrade.

https://github.com/DioxusLabs/dioxus/blob/e2e565c8895a489fbe530cad14fae63c673cd337/packages/cli/src/build/verify.rs#L58-L81

Unfortunately, now that wasm-bindgen is pinned with ="0.2.99" this doesn't work anymore.

❯ cargo update -p wasm-bindgen --precise 0.2.97
    Updating crates.io index
error: failed to select a version for the requirement `wasm-bindgen = "=0.2.99"`
candidate versions found which didn't match: 0.2.97
location searched: crates.io index
required by package `web-sys v0.3.76`
    ... which satisfies dependency `web-sys = "^0.3.61"` (locked to 0.3.76) of package `dioxus-fullstack v0.6.0`
    ... which satisfies dependency `dioxus-fullstack = "^0.6.0"` (locked to 0.6.0) of package `dioxus v0.6.0`
    ... which satisfies dependency `dioxus = "^0.6.0"` (locked to 0.6.0) of package `reduuu v0.1.0 (/Users/jonkelley/Development/Tinkering/06-testing/reduuu)`

Users have no choice but to upgrade to the latest wasm-bindgen version.... But there's no way we can update the dioxus-cli in time so our tooling will simply stop working and everyone's projects just won't work.

wasm-bindgen should REALLY not be pinned to an exact version

[daxpedda]

Is this a request to revert #4291?
Or is this a response to pinning to avoid breaking changes?