Change:
<ins> // force-host // no-prefer-dynamic #![crate_name = "reproduction"] #![crate_type = "proc-macro"] extern crate proc_macro; use proc_macro::TokenStream; #[proc_macro] pub fn mac(input: TokenStream) -> TokenStream { input } </ins>

Discussion:
Reproduction (as an UI test): Name resolution will try to load the crate twice, first in initial pass, then in validation pass. The results will be different due to different loaded s, so we get the "inconsistent resolution for a macro" assertion. This happens due to the condition in preventing reuse of s for host crates during cross-compilation. cc probably
If I'm not mistaken, the issue will affect any idiomatic Rust 2018 code trying to use proc macros together with cross-compilation.
The workaround is to avoid using host crates through extern prelude and use them through items instead, like it's done in
Sorry for the late delay in checking in on this. This is somewhat expected in the sense that we load proc-macro crates from the compiler's target and the actual target differently as they may be two different crates. That was done a really long time ago and I never really followed all of the macro developments and how they affected cross compilation. We can probably add a function that compares two CrateNum instances though to see if they only differ by target and maybe that'd help here?
Posting a typical message and backtrace here to make this issue easier to find:
It would be great if someone come up with a short-term fix for this, perhaps hacky. Otherwise I hope to get to this in June and fix it together with a few other issues in crate loading.
Alternative short term solution just to make things compile (probably): disable the validation asserts mentioned here and in the linked issues if host != target. The validation provided by the host = target case should be good enough for checking that there are no issues in name resolution itself (excluding crate loading). Someone need to try it and check whether it works. It's quite possible that the crate ID multiplication only causes slowdowns. It's also possible that something like type errors will follow and will be considered a different type from another .
i am having the same issue as in and i want to do short term solution, but i am not sure how to apply it, can you please explain?
Find the assert causing the issue, it should be one of the three "inconsistent resolution" asserts in . Remove the assert. Build the compiler and run some tests . Add the freshly built toolchain to rustup () Try to cross-compile your project using this toolchain and see what happens.

Otherwise I hope to get to this in June and fix it together with a few other issues in crate loading. It's not June anymore, but I finally started working on crate loading (). Hopefully I'll get to this issue too, but I'll probably have to do some cleanups first because crate loading is still very messy and it's not clear when exactly crates can be considered "already loaded" and retrieved from the cache.
i solved my problem by using instead of
In case it helps others: using an explicit path also does the trick (e.g. ). This is helpful to keep the source and the build system of a project closest to what it will be when this is solved.
The error for this currently looks like which comes from I think is the function that determines whether a CrateNum should be reused.
This still causes an ICE when trying to import more than one proc macro at a time as observed in
do you remember what you meant by this? Why could they be different crates? Proc-macros are always compiled for the host, so they should be the same even when cross-compiling. In general, I'm not sure when this could go wrong - the compiler already checks if the target doesn't match and gives an error: So I'm not sure why we have to check again when loading the dependency. I don't think it's possible to load two crates compiled for different targets at the same time, even without this check, it will only load the crate that matches .
does it also make sense to add the test case described in ? Would be nice if the ICE got resolved by your change as well
how is that test case different from ?
I my testing I found that the compiler shows an error when you import one proc macro and panics with an ICE as soon as you import two or more proc macros from the same crate. I would suspect your change fixes both but we might still to check just to be sure
I can't replicate that ICE.
I can still replicate the issue, both with stable and nightly: I'm using this repo for testing:
The only difference I can spot in which file is, I have it in the proc macro crate and you seem to have in in the main file (unless the lines just got mixed up in your comment)
Sorry it's been so long I don't really remember most of this code here any more.