creader: Host crate loaded twice produces different `CrateNum`s if host != target

[petrochenkov]

Reproduction (as an UI test):

// force-host
// no-prefer-dynamic

#![crate_type = "proc-macro"]

extern crate proc_macro;
use proc_macro::TokenStream;

#[proc_macro]
pub fn mac(input: TokenStream) -> TokenStream {
    input
}

// edition:2018
// compile-flags:--extern reproduction
// aux-build:reproduction.rs

reproduction::mac!();

fn main() {}

# Assuming x86_64-unknown-linux-gnu host
./x.py test --bless --stage 1 --target i686-unknown-linux-gnu src/test/ui --test-args reproduction

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 CrateNums, so we get the "inconsistent resolution for a macro" assertion.

This happens due to the locate_ctxt.triple == &self.sess.opts.target_triple condition in CrateLoader::load preventing reuse of CrateNums for host crates during cross-compilation.

cc @alexcrichton probably

[petrochenkov]

If I'm not mistaken, the issue will affect any idiomatic Rust 2018 code trying to use proc macros together with cross-compilation.

[petrochenkov]

The workaround is to avoid using host crates through extern prelude and use them through extern crate items instead, like it's done in a5d4544.

[alexcrichton]

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?