Skip to content

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

New issue

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

#

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Jump to bottom
Closed
gui1117 opened this issue Sep 14, 2019 · 7 comments
Closed

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

gui1117 opened this issue Sep 14, 2019 · 7 comments
Assignees
@petrochenkov
Labels
A-cross Area: Cross compilation A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) A-resolve Area: Name/path resolution done by `rustc_resolve` specifically C-bug Category: This is a bug. I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@gui1117
Copy link
Contributor

gui1117 commented Sep 14, 2019

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
Copy link
Contributor

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
Copy link
Contributor

bkchr commented Sep 25, 2019

@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?

@jonas-schievink jonas-schievink added A-cross Area: Cross compilation A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) A-resolve Area: Name/path resolution done by `rustc_resolve` specifically C-bug Category: This is a bug. I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Sep 25, 2019
@petrochenkov petrochenkov self-assigned this Sep 26, 2019
@petrochenkov
Copy link
Contributor

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
Copy link
Contributor

bkchr commented Sep 26, 2019

Nice, ty! :)

@petrochenkov
Copy link
Contributor

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 petrochenkov mentioned this issue Oct 2, 2019
Merged
@petrochenkov
Copy link
Contributor

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

Centril added a commit to Centril/rust that referenced this issue Oct 3, 2019
@Centril
Rollup merge of rust-lang#65026 - petrochenkov:ice1, r=eddyb
7af56ad 
metadata: Some crate loading cleanup

So, my goal was to fix caching of loaded crates which is broken and causes ICEs like rust-lang#56935 or rust-lang#64450.
While investigating I found that the code is pretty messy and likes to confuse various things that look similar but are actually different.
This PR does some initial cleanup in that area, I hope to get to the caching itself a bit later.
Centril added a commit to Centril/rust that referenced this issue Oct 4, 2019
@Centril
Rollup merge of rust-lang#65026 - petrochenkov:ice1, r=eddyb
a16c637 
metadata: Some crate loading cleanup

So, my goal was to fix caching of loaded crates which is broken and causes ICEs like rust-lang#56935 or rust-lang#64450.
While investigating I found that the code is pretty messy and likes to confuse various things that look similar but are actually different.
This PR does some initial cleanup in that area, I hope to get to the caching itself a bit later.
@petrochenkov petrochenkov mentioned this issue Oct 5, 2019
Closed
@tesuji tesuji mentioned this issue Oct 10, 2019
Closed
@jonas-schievink jonas-schievink mentioned this issue Oct 30, 2019
Closed
@alexlapa alexlapa mentioned this issue Nov 21, 2019
Merged
tyranron pushed a commit to instrumentisto/tracerr-rs that referenced this issue Nov 22, 2019
@alexlapa @tyranron
Fix panic on 'wasm32-unknown-unknown' target (#1)
c81ab7a 
See: rust-lang/rust#64450
@jonas-schievink jonas-schievink mentioned this issue Dec 9, 2019
Closed
This was referenced Dec 10, 2019
Closed
Closed
bors bot added a commit to swc-project/swc that referenced this issue Dec 10, 2019
@bors @anurbol
Merge #494
d2be977 
494: Fixing the Wasm blocker for Parser r=kdy1 a=anurbol

Rust has a [bug](rust-lang/rust#64450) when compiling a project for Wasm (with `--target wasm32-unknown-unknown` flag), these changes are a workaround.

These changes are only supposed to fix the SWC Parser, not the whole SWC project. This is because I only need the Parser at the moment, also fixing the whole SWC Project would be a nightmare for me, a newbie in SWC. Maybe later.

Co-authored-by: Nurbol Alpysbayev <anurbol@gmail.com>
@anurbol anurbol mentioned this issue Dec 10, 2019
Merged
This was referenced Feb 10, 2020
Merged
Closed
@realcr realcr mentioned this issue Mar 5, 2020
Merged
danielhenrymantilla added a commit to danielhenrymantilla/next-gen-rs that referenced this issue Mar 31, 2020
@danielhenrymantilla
Fix rust limitation as per rust-lang/rust#64450
4222909
@petrochenkov petrochenkov mentioned this issue May 8, 2020
Closed
@petrochenkov
Copy link
Contributor

Closing as a duplicate of #56935.

zaxguo pushed a commit to zaxguo/libra that referenced this issue Jul 2, 2020
address deps but rustc crashed -- potentially due to crates renaming …
b5be32f 
…issue ini rust-lang/rust#64450
# for free to join this conversation on GitHub. Already have an account? # to comment
Assignees

@petrochenkov petrochenkov

Labels
A-cross Area: Cross compilation A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) A-resolve Area: Name/path resolution done by `rustc_resolve` specifically C-bug Category: This is a bug. I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@jonas-schievink @bkchr @petrochenkov @gui1117