You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While trying to build Swift Foundation master branch, I am hitting a issue when importing <stdint.h> from CoreFoundation header files. The Swift compiler is complaining about having to import first from the SwiftGlibc.C.pty module and then crashes with a assertion error.
NOTE: I have redacted the log a little bit for readability (see the full log below).
It seems that if I replace <stdint.h> with these 4 headers, the compiler stops complaining about the UInt needing the module, but the assertion still triggers and crashes the compiler.
Some context of the changes I have currently to make the compiler, stdlib and Foundation to (not) build:
On swift/lib/Runtime/Config.h I have enabled SWIFT_USE_SWIFTCALL for FreeBSD systems (it looks like __has_attribute(swiftcall) is evaluating to false even though the intrinsic is available).
#ifndefSWIFT_USE_SWIFTCALL// Clang doesn't support mangling functions with the swiftcall attribute// on Windows and crashes during compilation: http://bugs.llvm.org/show_bug.cgi?id=32000
#if (__has_attribute(swiftcall) || defined(__linux__) || defined(__FreeBSD__)) && defined(_WIN32) && !defined(__FreeBSD__)
#defineSWIFT_USE_SWIFTCALL1
#else
#defineSWIFT_USE_SWIFTCALL0
#endif
#endif
On swift/stdlib/public/SwiftShims/SwiftStdint.h & swift/stdlib/public/SwiftShims/SwiftStddef.h:
I have added a extra !defined(FreeBSD). This did not seem to make any difference on the error.
// stdint.h is provided by Clang, but it dispatches to libc's stdint.h. As a
// result, using stdint.h here would pull in Darwin module (which includes
// libc). This creates a dependency cycle, so we can't use stdint.h in
// SwiftShims.
// On Linux, the story is different. We get the error message
// "/usr/include/x86_64-linux-gnu/sys/types.h:146:10: error: 'stddef.h' file not
// found"
// This is a known Clang/Ubuntu bug.
// Clang has been defining __INTxx_TYPE__ macros for a long time.
// __UINTxx_TYPE__ are defined only since Clang 3.5.
#if !defined(__APPLE__) && !defined(__linux__) && !defined(__FreeBSD__)
#include <stdint.h>
...
#else
...
#endif
swift-corelibs-foundation/lib/target.py made the changes as per the patch included in the FreeBSD ports repository. The other patches no longer seem necessary.
On all swift-corelibs-foundation/Foundation/.swift* I have added a #if os(FreeBSD) where appropriate.
The text was updated successfully, but these errors were encountered:
This is probably a Clang issue more than a Swift issue. The fastest way to work around it might just be to include the header that it's complaining about (whichever header corresponds to SwiftGlibc.C.pty).
I am now facing a another, but maybe related, issue when compiling libdispatch. In this case, I get the same assertion claiming "Declaration not emitted!" but no include error. I will try to investigate further and create another issue about it.
A year later: our Clang folks think this is fixed in the swift-5.0-branch. Mind trying again with a development snapshot from https://swift.org/download ?
Additional Detail from JIRA
md5: db94691cb055495db7eb13025b3708ee
Issue Description:
While trying to build Swift Foundation master branch, I am hitting a issue when importing <stdint.h> from CoreFoundation header files. The Swift compiler is complaining about having to import first from the SwiftGlibc.C.pty module and then crashes with a assertion error.
NOTE: I have redacted the log a little bit for readability (see the full log below).
It seems that if I replace <stdint.h> with these 4 headers, the compiler stops complaining about the UInt needing the module, but the assertion still triggers and crashes the compiler.
Simple hello world programs are working fine.
Error output
Some context of the changes I have currently to make the compiler, stdlib and Foundation to (not) build:
On swift/lib/Runtime/Config.h I have enabled SWIFT_USE_SWIFTCALL for FreeBSD systems (it looks like __has_attribute(swiftcall) is evaluating to false even though the intrinsic is available).
On swift/stdlib/CMakeLists.txt (for SR-5779)
On swift/stdlib/public/SwiftShims/SwiftStdint.h & swift/stdlib/public/SwiftShims/SwiftStddef.h:
I have added a extra !defined(FreeBSD). This did not seem to make any difference on the error.
swift-corelibs-foundation/lib/target.py made the changes as per the patch included in the FreeBSD ports repository. The other patches no longer seem necessary.
On all swift-corelibs-foundation/Foundation/.swift* I have added a #if os(FreeBSD) where appropriate.
The text was updated successfully, but these errors were encountered: