Types & functions generated by a macro aren't converted

[neon64]

After looking through the issues in syntex (https://github.com/serde-rs/syntex/issues/45), I am fairly sure it is their issue not yours, but I thought I would ask anyway.

I have a macro like this:

#[macro_export]
macro_rules! opaque_struct {
    ($inner:ty, $opaque:ident, $opaqueBoxed:ident, $deleteFunction:ident) => {
        #[repr(C)]
        pub struct $opaque(pub $inner);

        // ...and so on
    }
}

The #[repr(C)] structs and extern functions aren't converted to the C header.

I also understand you are rewriting the code into a more general framework. Will that change the way macros are/aren't expanded?

A long term plan / ambitious idea

In the far future I think it would be great if rustc allowed multiple compilation 'targets', and users could then create targets that weren't actual targets for a specific processor. That sounds weird, but is perhaps best explained with examples:

• a "C header file" target, which would essentially be a really overpowered rusty-cheddar
• a "GLSL" or "SPIRV" target for GPU graphics/compute (a really overpowered version of my hacky https://github.com/neon64/rust_to_glsl_lint)

The key differentiating factor between this system and lints/syntax extensions/build scripts would be that it would have access to ALL type information and the implementation/MIR of ALL crates (currently only generic functions/structs from foreign crates are put into metadata and made available to lints/trans).

If you think that is an interesting proposition taking to http://internals.rust-lang.org or whatever, then let me know.

[Sean1708]

Hi @neon64, sorry I couldn't reply earlier.

I think you're right that this is an upstream bug, but I'll still keep it in the back of my mind since I could be wrong.

As for the long term plan, I like the idea but I'm not sure it provides enough of an advantage for the amount of effort it would take (since I think you would end up having to reimplement 50% of a C compiler backend) and I certainly won't have the time to spear-head it for the next few months.

[habnabit]

Having this problem too. Probably going to use --unpretty=expanded as a half-measure.