Rustflags ignored(?) when cross compiling a proc-macro crate

fn main() {
    // this should emit a warning, but is an error unless is removed
    let _x = 3.14;

    // opposite here, this should be an error
    unsafe {
        let px = 0 as *mut i32;


target = "x86_64-pc-windows-gnu"

rustflags = [
    # BEGIN - Embark standard lints v6 for Rust 1.55+
    # Do not change or add/remove here, but one can add exceptions after this section
    # for more info see: <>
    # END - Embark standard lints v6 for Rust 1.55+

    # Seems to help but causes rust-analyzer failing cargo check
    # "--target=x86_64-pc-windows-gnu",

runner = "wine"


name = "aaa"
version = "0.1.0"
edition = "2021"

proc-macro = true


If I remove then everything works fine. If I then add "--target=x86_64-pc-windows-gnu" to rustflags, it seems linting works though this causes rust-analyzer and the like to specify target twice, causing building to fail. I've also seen cross but it doesn't help here.

Also, if I make this a regular library instead, everything works fine.

Anybody know what I'm doing wrong/should change?

Before that can be discussed maybe it's good idea to first discuss what are you trying to achieve?

Because “cross-compilation of proc-macro crate” is something that's, technically, possible but utterly pointless and useless, most of the time: you couldn's use such crate to compile something, you can only ship it, together with the appropriate version of the compiler (remember that compiler ABI in unstable) to someone and that receiver of your crate would be able to use it compile… something.

Is this what you want to achieve?

Because usually proc-macro crates are built natively even if you are compiling everything else for the other platform — because that means the most sense. In such a case they would be usable to build other code which is what you usually want.

I'm trying to create a macro that'll forward another dll's symbols, this macro would not be in any public API and would just make a small portion of code cleaner (rather than needing to write to the drectve section over and over again using inline assembly, or using a .def file for instance, you could just specify a path and it'll do all this for you). This is for building a proxy DLL that'll be ran by a game (consensually, of course) only available natively on Windows, so if I don't forward/reexport its symbols then it may not function properly, or outright not open. I'm only targeting x86_64-pc-windows-gnu because of this so I thought forcing builds to that would work fine, though I might be mistaken.

Yeah, this makes sense, and also wouldn't be an issue. Though from what I've seen (though which could be very wrong), specifying a target in cargo/config.toml affects all crates, including proc-macros. Is there potentially a workaround for this case?

e: I should also clarify that compiling goes perfectly fine, it forwards everything as would be expected. It's just that rustflags is ignored, at least in the case of clippy. This is a bit inconvenient, even if it would only affect code in this one crate.

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.