Cargo uses the target-triplet, should be host-triplet, to compile proc-macro

[lukaslueg]

Coming over from rust-lang/rust#52707

tl;dr: Cargo fails to compile a crate with a dependency on proc_macro for wasm32. @eddyb suggested that the underlying problem is not with rustc but cargo using the target-triplet to compile proc-macro, while it should be using the host-triplet.

proc-macro is missing from the distribution for wasm32:

$ ls ~/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib | grep proc_macro
libproc_macro-1ea4ba9e4f6cdbc1.so

$ ls ~/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/wasm32-unknown-unknown/lib | grep proc_macro

...which causes anything that depends on proc-macro2 somewhere down the tree to be unable to compile to wasm:

$ cargo new foobar
$ cd foobar
$ echo 'proc-macro2 = "*"' >> Cargo.toml
$ cargo build --target=wasm32-unknown-unknown
   Compiling unicode-xid v0.1.0                                                                                                                                                                                                              
   Compiling proc-macro2 v0.4.9
error[E0463]: can't find crate for `proc_macro`
  --> /home/kou/.cargo/registry/src/gh.neting.cc-1ecc6299db9ec823/proc-macro2-0.4.9/src/lib.rs:50:1
   |
50 | extern crate proc_macro;
   | ^^^^^^^^^^^^^^^^^^^^^^^^ can't find crate

... which in turn is very sad because proc-macro2 is needed not just for procedural macros but also to "just" parse rust code and having anything depend on a crate which in turn depends on proc-macro2 effectively prohibits compiling for the web. May it be possible to include proc-macro in the wasm32-target ?

In fact, all I need is proc_macro2::{Delimiter, Ident, Literal, Punct, TokenStream}

[eddyb]

Wait, you're using cargo build on the proc macro crate? I thought proc macro crates could only be built as dependencies of regular crates, otherwise Cargo can't tell it needs to build for the host.

May it be possible to include proc-macro in the wasm32-target ?

That's not useful for actual proc macros, but I might be misunderstanding your usecase. proc_macro doesn't work (will panic) outside of macro expansion, and unless proc_macro2 does anything clever, it will just fail when attempted to be used outside an actual proc macro.

[alexcrichton]

Yes as mentioned by @eddyb this sequence of steps isn't a bug in Cargo, but you can try turning off the proc-macro feature of proc-macro2 to get this working.

[lukaslueg]

I've reopened the bug with cargo-web, yet after some investigation, I suspect this is still a problem with cargo and I'd like to re-open here.

• The target is wasm32-unknown-unknown, using cargo-web to build (should be irrelevant actually)
• The main crate has a dependency on stdweb = "0.4", which in turn has an internal proc-macro=true crate that only builds on wasm-targets and the like.
• The main crate also has a dependency on proc-macro2 = { version = "0.4", default_features = false }. proc_macro is therefore not needed.

If either of the two dependencies is commented out, the build for wasm32-unknown-unknown works fine. However, if both are enabled, cargo fails due to proc_macro not being found while building proc_macro2.

The proc-macro feature is enabled for the direct dependency on proc-macro2 - even though default_features = false - because the proc_macro=true from stdweb-internal-macros seems to be leaking (similar to this).

I've tried to [replace] my own dependencies (syn, quote, proc-macro2), so they don't react at all to the proc-macro-feature. But, alas, this would replace the dependencies on those crates for stdweb-internal-macros as well, causing it to fail building. Also, [replace] does not work when specified by a dependency, so I can't micro-manage that.

I only solution I see is to vendor all of syn, quote and proc-macro2, rip out the proc-macro specific stuff and use those path-specific dependencies for the wasm32-unknown-unknown target. This would, however, heavily pollute what would otherwise be a clean dependency that knowns nothing about the target it is built for.

[alexcrichton]

@lukaslueg I think the best solution here is to just fix proc-macro2 itself, disabling linking to proc_macro on platforms that are known to not have it, like wasm.

[lukaslueg]

@alexcrichton syn and quote have the same problem, so they would need fixing as well, in addition to all other crates which have a proc-macro-feature. In my case some older versions of proc-macro2 appear in the dependency tree as well, although that could be updated with the help of their respective owners involved.

Instead of fixing every crate out there that has this problem, couldn't we make cargo hide the proc-macro feature for those targets?

[alexcrichton]

We could perhaps, but that's not at all a Cargo issue and is an issue for rust-lang/rust. In the meantime it'll likely be easiest to fix this in proc-macro2 and other crates.

[vitiral]

This seems to be happening for me on only windows because I depend on yew -> failure -> proc_macro2.

It doesn't seem to cause a problem on linux/mac.

https://travis-ci.org/vitiral/artifact/builds/471179142?utm_source=github_status&utm_medium=notification

[vitiral]

I assume this is related to dtolnay/proc-macro2#111

[lukaslueg]

dtolnay/proc-macro2#111 is the "fix" for this, although all crates with a feature like this will fail to build if they do not specifically exclude wasm. asmjs should also be ignored, which I did not fix and still fails.