NotificationsYou must be signed in to change notification settings
Fork341
Star4k

fix wasm + no-std cargo interactions#864

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Jump to bottom

Closed

jbr wants to merge11 commits intoasync-rs:masterfromjbr:tmp-no-cache-in-ci

Closed

fix wasm + no-std cargo interactions#864

jbr wants to merge11 commits intoasync-rs:masterfromjbr:tmp-no-cache-in-ci

Conversation

Copy link

Contributor

jbr commentedAug 25, 2020•
edited
Loading

This started as an extension of#863 disabling the build cache in ci and turned into an investigation of a cargo bug that pulls in wasm deps for no-std, breaking ci. The proposed fix in this pr alsocloses#823

jbrand others added9 commits

August 13, 2020 21:38

run ci on wasm32-unknown-unknown

047847f

use cargo cache and matrix rust

5342950

fix yaml format

8afc6a7

first fixes

7d7af99

Merge branch 'run-ci-on-wasm-target' ofhttps://github.com/jbr/async-std

c461a53

 into jbr-run-ci-on-wasm-target

Merge branch 'jbr-run-ci-on-wasm-target' into fix-wasm

b53cd36

check unstable

04cc2fd

fix wasm32 compiles

d0d277d

temporary: test if not using the build cache resolves confusing ci issue

e6a1e16

Copy link

ContributorAuthor

jbr commentedAug 25, 2020•
edited
Loading

@dignifiedquire It seems like this sledgehammer-fix resolves the macos issue, but I think the no-std failure is real. I get it locally as well.

Edit: I think maybe this is a cargo bug? 🙃

$ cargo check --no-default-features --features alloc --target thumbv7m-none-eabi -Z avoid-dev-deps --verbose       Fresh pin-project-lite v0.1.7    Checking futures-core v0.3.5     Running`rustc --crate-name futures_core --edition=2018 /Users/jbr/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-core-0.3.5/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type lib --emit=dep-info,metadata -Cembed-bitcode=no -C debuginfo=2 --cfg'feature="alloc"' --cfg'feature="default"' --cfg'feature="std"' -C metadata=6587bfddd05ac72e -C extra-filename=-6587bfddd05ac72e --out-dir /Users/jbr/code/async-std/target/thumbv7m-none-eabi/debug/deps --target thumbv7m-none-eabi -L dependency=/Users/jbr/code/async-std/target/thumbv7m-none-eabi/debug/deps -L dependency=/Users/jbr/code/async-std/target/debug/deps --cap-lints allow`error[E0463]: can't find crate for `std`

note the--cfg 'feature="std"' — that makes no sense. Somehow--no-default-features is getting ignored andstd is getting added back in???

Further digging:
Disabling the target_arch = "wasm32" dependencies and dev-dependencies lines fixes no-std. Somehow they're getting enabled even though they shouldn't be active.

Proposed fix:

This PR includes changes that would fix several issues in async-std regarding wasm, but has a cost: Wasm users will have to enable a mandatorywasm feature. This also would address the issue where wasm deps were getting pulled in on non-wasm platforms (#823)