Allow the use of syntax extensions when cross-compiling #13584
Conversation
|
This is an alternative to #13450 |
| } | ||
| compile_aux_args(&aux_props); | ||
| } |
There was a problem hiding this comment.
These changes to compiletest are optional, I wrote them when attempting to get phase-syntax-link-does-resolve to work when cross-compiling, but currently there is the difficulty of libsyntax being required at runtime when this kind of crate is used. The capability may be useful in the future when this can be resolved, however.
There was a problem hiding this comment.
I'm not sure I quite follow these changes, could you add some comments or explain them to me?
There was a problem hiding this comment.
Note that requiring a target libsyntax is a bug and the tests should be updated to not do that.
There was a problem hiding this comment.
This is difficult to do currently (specifically phase-syntax-link-does-resolve involves a crate from which normal functions and syntax extensions are loaded, which is a desirable feature). I think it could be done with conditional extern crate; and some #[cfg(no_syntax)] build or similar.
|
I've reworked the code as suggested, it involves a few more changes, but I think it's probably a bit cleaner overall (the most awkward bit is moved to load_crate in CrateLoader). |
| decoder::get_symbol(data.data.as_slice(), id) | ||
| let target_triple = self.env.sess.targ_cfg.target_strs.target_triple.as_slice(); | ||
| let is_cross = target_triple == driver::host_triple(); | ||
| let should_link = info.should_link && is_cross; |
There was a problem hiding this comment.
Should this condition use !is_cross instead of is_cross? It may also be clearer to get inlined below.
There was a problem hiding this comment.
It should be is_cross. It only makes sense to search twice if we're cross compiling and there are two sets of libraries to search.
There was a problem hiding this comment.
Ah, I think I see what's going on, I think some comments may be in order (down on the if condition).
This also looks like if you have a host crate with macros (but no target crate), you will attempt to link against it?
There was a problem hiding this comment.
oops, you are indeed correct, I misunderstood initially.
|
This is looking great, thanks again for this! |
|
Squashed and rebased |
|
Requested cleanup done. |
|
This looks good to me, thanks! I'm going to test the i686<->x86_64 configuration before landing to make sure our snap/nightly builders continue working (will post back here when it's done) |
|
Looks like this does the trick! There's one more test ( |
This adds the target triple to the crate metadata. When searching for a crate the phase (link, syntax) is taken into account. During link phase only crates matching the target triple are considered. During syntax phase, either the target or host triple will be accepted, unless the crate defines a macro_registrar, in which case only the host triple will match.
|
Done. |
This allows the use of syntax extensions when cross-compiling (fixing #12102). It does this by encoding the target triple in the crate metadata and checking it when searching for files. Currently the crate triple must match the host triple when there is a macro_registrar_fn, it must match the target triple when linking, and can match either when only macro_rules! macros are used. due to carelessness, this is pretty much a duplicate of #13450.
…r=jonas-schievink fix: fix panic when computing signature of generic `FnOnce` callable Fixes rust-lang/rust-analyzer#13579
…rednet borrow_deref_ref: do not trigger on `&raw` references changelog: [`borrow_deref_ref`]: do not trigger on `&raw` references Fix rust-lang#13584
…rednet borrow_deref_ref: do not trigger on `&raw` references changelog: [`borrow_deref_ref`]: do not trigger on `&raw` references Fix rust-lang#13584
This allows the use of syntax extensions when cross-compiling (fixing #12102). It does this by encoding the target triple in the crate metadata and checking it when searching for files. Currently the crate triple must match the host triple when there is a macro_registrar_fn, it must match the target triple when linking, and can match either when only macro_rules! macros are used.
due to carelessness, this is pretty much a duplicate of #13450.