dstep
dstep copied to clipboard
Multiple clashing definitions of opaque types
This is quite interesting design challenge for dstep. Consider common situation where you have multiple headers in library looking like this:
// header 1
struct opaque_s;
void do_things_with(struct opaque_s*);
// header 2
struct opaque_s;
void do_other_things_with(struct opaque_s*);
In C all those opaque definitions collapse into one because there are no modules. In D, however, each header will become own module and compiler will detect two different symbols with same mangling, like this:
Error: module1.opaque_s at module1.d(42) conflicts with module2.opaque_s at module2.d(42)
Natural solution that comes to my mind is to separate all opaque types into own separate module and do public aliases of those symbols in modules they are originally placed. What do you think?
Natural solution that comes to my mind is to separate all opaque types into own separate module and do public aliases of those symbols in modules they are originally placed. What do you think?
Yeah, it seems like an acceptable solution (I don't like that additional module, but it is unavoidable). Another idea would be to import the symbol from one module into the other one (and maybe alias it)...
I haven't checked translqtor sources in a while - does it currently process all files completely in parallel or some global state is tracked?
All files are translated independently, there is no shared state.
Makes sense. The change I envision would be for each translation task to produce list of opaque types when finished (if multi file mode is used) and merge them into one shared aggregator. Then generare dedicqted module from it at the end of all translation.