[2.079] Only emit interface vtables in the declaring module

[kinke]

No description provided.

[kinke]

Fixes the linking errors on OSX.

On 64-bit OSX, the C++ mangling of 64-bit integers still needs to be figured out (long vs. long long?); the 5th commit was required to get rid of linking errors for the all target (incl. ldc-prune-cache tool etc.), but there are still related failures for dmd-testsuite (runnable/{cppa,externmangle}.d). All other 2.079 tests green on OSX (except for the minimal runtime ones fixed by #2641).
Edit: Ah, it's https://dlang.org/changelog/2.079.0.html#fix18053.

[kinke]

OSX mangling should be fixed now, incl. self-compilability of 2.079. The breaking change affects size_t (and ptrdiff_t) too, as it's defined as alias to u{int,long} in object.d; this means that a 64-bit D size_t is now mangled as C++ uint64_t (unsigned long long on 64-bit OSX), which on 64-bit OSX doesn't correspond to C++ size_t anymore (apparently a unsigned long).
Luckily, we apparently only use very few cross-language calls with size_t args, so adapting the type in the C++ headers wasn't hard, but there are many more C++ function declarations which would actually need to be changed from size_t to d_size_t to fix all potential linking errors.

Additionally, it looks as if a C++ size_t cannot be represented in D on 64-bit OSX at all anymore. One would think that core.stdc.config.c[pp]_ulong would fit the bill, but I think it doesn't: https://github.com/ldc-developers/druntime/blob/ldc-merge-2.079/src/core/stdc/config.d#L67-L71 (should require a magic struct and appropriate handling by the compiler)

[kinke]

I'm not the only one finding the mangling change at least problematic:
dlang/dmd#7523
dlang/dmd#7416

[JohanEngelen]

it looks as if a C++ size_t cannot be represented in D on 64-bit OSX at all anymore.

Wow. :( That would mean we lost C++ interop (modifying C++ is unacceptable in many cases). Unacceptable if you ask me.

[kinke]

Absolutely. Even when fixing core.stdc.config by providing cpp_[u]long and cpp_{size,ptrdiff}_t, I think having a D size_t naturally C++-mangled as the corresponding C++ size_t is one of the most important things for easy-peasy D <--> C++ interop, as a size_t should be much more frequently used than explicit 64-bit integer types (for which one could resort to a new core.stdc.config.[u]int64_t, matching C++ [u]int64_t mangling).

[kinke]

The test confirms the regression on 64-bit macOS. It also shows that 32-bit size_t C++ mangling has already been broken for 32-bit macOS (D (size_t being an alias for uint): unsigned int vs. C++ unsigned long apparently).

[JohanEngelen]

We are already ABI incompatible with DMD and GDC, iirc, so I'm fine with fixing the mangling ourselves if upstream dfrontend doesn't want to.

[kinke]

Walter doesn't seem to acknowledge the size_t interop problem and is going for a core.stdc.config.cpp_size_t alias (while at least getting rid of the separate implicit conversion issue of the magic structs) in dlang/druntime#2160.

I reverted the mangling and added aliases c(pp)_(u)longlong and c(pp)_(u)int64_t. 32-bit macOS aside, this makes sure D/C++ size_t still match on all tested platforms. For (the in my experience way less often used) C++ (u)int64_t, one needs to resort to cpp_(u)int64_t for portable code (it's D (u)long everywhere except for 64-bit macOS). Any opinions @klickverbot @redstar?

[I'll split off the mangling things as separate PR. I just abused this PR here as the interface vtable emission fix is a prerequisite for running the CI tests on macOS.]

[JohanEngelen]

So DMD's core.stdc.config.cpp_size_t alias does correctly mangle to C++'s size_t on all platforms? If that's the case, then the problem is less big than I thought. (I thought it had become completely impossible to write a D function signature that would mangle to a C++ function with size_t)

[kinke]

So DMD's core.stdc.config.cpp_size_t alias does correctly mangle to C++'s size_t on all platforms?

Yep it will. With the magic struct -> enum change, the implicit conversion problem will be gone as well. Previously, no normal D size_t would have been implicitly converted to a cpp_size_t aliasing a magic struct.

I thought it had become completely impossible to write a D function signature that would mangle to a C++ function with size_t

That's the status quo for DMD 2.079.0 on 64-bit macOS (unless you roll your own magic __c_ulong struct).