druntime: Fix core.stdc.stdint.(u)int64_t on 64-bit macOS etc.#2700
druntime: Fix core.stdc.stdint.(u)int64_t on 64-bit macOS etc.#2700kinke merged 1 commit intoldc-developers:masterfrom
Conversation
4770ebe to
3d8b1bd
Compare
|
Related: #2650 I find this mangling situation very unfortunate :( Sorry if asking the same question again, I forgot the answer. Is it now that from 2.079 onwards it is necessary to use different D types for C++ interop with DMD and LDC? Is there any way we can prevent that? (either convince DMD to do what we think is sane, or change LDC to do what DMD thinks is sane?) |
|
A short summary:
|
What does "it" refer to here? D |
|
The above summary is all 64-bit macOS specific, except for the parts where I mentioned 32-bit macOS and 'other platforms'. So 'it = D (u)long on 64-bit macOS and thus D {size,ptrdiff}_t on 64-bit macOS`. |
|
[On Windows/MSVC, D [Oh and D long is C++ long on all other 64-bit POSIX platforms (and C++ |
* Use it instead of newly introduced, LDC-specific
`core.stdc.config.c(pp)_(u)int64_t`.
* Cherry-pick Walter's upstream commit replacing the magic structs in
core.stdc.config by magic enums (supporting implicit conversion from
integer literals) [as well as adding cpp_{size,ptrdiff}_t].
* Add a clarifying comment wrt. DMD/LDC mangling difference on 64-bit
OS X and use version(LDC) guards.
* Fix cpp_ptrdiff_t for 32-bit macOS.
* Adapt dmd-testsuite accordingly.
core.stdc.config.c(pp)_(u)int64_t.core.stdc.configby magic enums (supporting implicit conversion from integer literals) [as well as addingcpp_{size,ptrdiff}_t].version(LDC)guards.