rustc panic with `inconsistent resolution for a macro` for proc macro imported different name for wasm target.

[gui1117]

Context

I compile with cargo check --target=wasm32-unknown-unknown for a project with a proc macro imported with a different name as such:

[dependencies]
curve = { package = "srml-staking-npos-reward-curve", path = "../npos-reward-curve"} // proc macro

and it fails with:

[thiolliere@localhost runtime]$ cargo check --target=wasm32-unknown-unknown --verbose
       Fresh srml-staking-npos-reward-curve v2.0.0 (/home/thiolliere/Developpement/debug-inconsistence/npos-reward-curve)
    Checking node-runtime v2.0.0 (/home/thiolliere/Developpement/debug-inconsistence/runtime)
     Running `rustc --edition=2018 --crate-name node_runtime src/lib.rs --color always --crate-type lib --emit=dep-info,metadata -C debuginfo=2 -C metadata=725a3230f86358ca -C extra-filename=-725a3230f86358ca --out-dir /home/thiolliere/Developpement/debug-inconsistence/runtime/target/wasm32-unknown-unknown/debug/deps --target wasm32-unknown-unknown -C incremental=/home/thiolliere/Developpement/debug-inconsistence/runtime/target/wasm32-unknown-unknown/debug/incremental -L dependency=/home/thiolliere/Developpement/debug-inconsistence/runtime/target/wasm32-unknown-unknown/debug/deps -L dependency=/home/thiolliere/Developpement/debug-inconsistence/runtime/target/debug/deps --extern curve=/home/thiolliere/Developpement/debug-inconsistence/runtime/target/debug/deps/libsrml_staking_npos_reward_curve-d12c78ed288d6d74.so`
thread 'rustc' panicked at 'src/librustc_resolve/macros.rs:928: inconsistent resolution for a macro', src/librustc/util/bug.rs:37:26
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports

note: rustc 1.37.0 (eae3437df 2019-08-13) running on x86_64-unknown-linux-gnu

note: compiler flags: -C debuginfo=2 -C incremental --crate-type lib

note: some of the compiler flags provided by cargo are hidden

error: Could not compile `node-runtime`.

Caused by:
  process didn't exit successfully: `rustc --edition=2018 --crate-name node_runtime src/lib.rs --color always --crate-type lib --emit=dep-info,metadata -C debuginfo=2 -C metadata=725a3230f86358ca -C extra-filename=-725a3230f86358ca --out-dir /home/thiolliere/Developpement/debug-inconsistence/runtime/target/wasm32-unknown-unknown/debug/deps --target wasm32-unknown-unknown -C incremental=/home/thiolliere/Developpement/debug-inconsistence/runtime/target/wasm32-unknown-unknown/debug/incremental -L dependency=/home/thiolliere/Developpement/debug-inconsistence/runtime/target/wasm32-unknown-unknown/debug/deps -L dependency=/home/thiolliere/Developpement/debug-inconsistence/runtime/target/debug/deps --extern curve=/home/thiolliere/Developpement/debug-inconsistence/runtime/target/debug/deps/libsrml_staking_npos_reward_curve-d12c78ed288d6d74.so` (exit code: 101)

removing the dependency renames works:

[dependencies]
srml-staking-npos-reward-curve = { path = "../npos-reward-curve"} // proc macro

Reproduce

use this repo: https://github.com/thiolliere/debug-inconsistence
and run cargo check --target=wasm32-unknown-unknown in the runtime crate.

[petrochenkov]

If cross-compilation is involved, then it might be a duplicate of #56935.
In that case the workaround is to use extern crate explicitly in source code, instead of relying on crate names passed with --extern automatically being in scope.

[bkchr]

@petrochenkov I had the same error with a different crate. It involves cross compilation, but as said by @thiolliere, this can be fixed by not including the proc-macro crate with renaming in the Cargo.toml file. So, I'm not entirely sure if that is that is a duplicate of the linked issue.

Any chance that this can be fixed in the near future? Could we maybe help you fixing this?

[petrochenkov]

I'll look into fixing it this weekend or the next week.
A minimized reproduction already exists, so the only helpful thing I can imagine is someone actually writing a fix and submitting a PR instead of me :)

[bkchr]

Nice, ty! :)

[petrochenkov]

This may be a slightly different issue from #56935, but the same workaround with adding extern crate to the crate root explicitly is confirmed to work.
(Like extern crate curve; for the reproduction example.)

[petrochenkov]

I started investigating in #65026, but didn't get to ICEs themselves yet.