resurrect emit-h

[McSinyx]

I am converting a codebase from C++ to Zig. So far, I switched the entry point to Zig and recreate the C++ objects in Zig. The rest in the middle are still (extern "C") C++, i.e. we have a Zig sandwich here.

In order for the C++ code to use the Zig struct, there must be a header file and unfortunately it is also translated to Zig. Thus, this shared module is recognized both as originally declared and .cimport[…].struct_[…] and the (stage 1) compiler yields the error: expected type […], found […]. I made a minimal reproducer here hoping it'll help debugging.

I also noticed that stage 1 compiler has disabled C header emission (GH-6753), was this one of the reasons?

[Vexu]

All struct types are unique, you cannot mix the automatically translated struct types with handwritten definitions.

[McSinyx]

I suppose the right way to do it here will be to ***@***.***` the struct from the C header? What should happen when the header is emitted by `zig build`? What I wrote by hand was identical to what -femit-h gives, except for the C++ compatibility.

[McSinyx]

Wow using emails with GitHub is awful, this is the original message:

I suppose the right way to do it here will be to @cImport the struct
from the C header? What should happen when the header is emitted
by zig build? What I wrote by hand was identical to what -femit-h
gives, except for the C++ compatibility.

[Vexu]

I suppose the right way to do it here will be to @cImport the struct
from the C header?

Either that or add casts where needed.

What should happen when the header is emitted
by zig build? What I wrote by hand was identical to what -femit-h
gives, except for the C++ compatibility.

Unless there is a dependency loop, this should be pretty easy to do by chaining a EmitHStep (once such exists), to a TranslateCStep and then using that as a package.

[McSinyx]

Wouldn't the translated struct from emitted header still be different from the original one? I don't see how that will make the useFoo(makeFoo()) call in Zig legal.

[babelchips]

I agree. I'm inclined to think we'll have different structs in play even when headers can be emitted.

For example when writing a combination of Zig and C code where you wish to share a Zig defined structure:

1. Emit a new Zig packed struct (assuming the emit feature exists)
2. Include the header in your C code
3. From C, call into an exported Zig function, passing the struct (or a reference to it) as an argument
4. Surely the compilation will fail with error: expected type […], found […] ... ?

You couldn't even use cImport with cInclude of the exported header back in Zig because the header file would not exist initially (or be out of date). Not that you would want to use imported versions of your own packed struct in the Zig code.

So, outside of using void* and casting either side, what is the ultimate solution here?

[SpexGuy]

You should define your structs in only one place. If you define them on the C side, you can cImport that in exactly one place, and everything will work. If you define them on the Zig side, you will also need to write your own extern function definitions, or post-process the generated .zig file from translate-c to fix up references.

[McSinyx]

You should define your structs in only one place.

Agreed, but this doesn't account for emitted structs. The only reason the struct was hand-written in the example was because emit-h has been disabled for stage 1 since 0.7. I think that seamless interoperation with C is one of the goals of Zig, and getting structures defined in Zig to work in C should be a supported use case, as it's crucial for writing C ABI libraries in Zig.

[andrewrk]

getting structures defined in Zig to work in C should be a supported use case, as it's crucial for writing C ABI libraries in Zig.

Completely agreed. The plan is to resurrect the emit-h feature in the self-hosted compiler, which is under active development.