Various cleanups to definitions in the runtime

include/swift/Runtime/Config.h

@@ -35,10 +35,10 @@
 /// Does the current Swift platform use LLVM's intrinsic "swiftcall"
 /// calling convention for Swift functions?
 #ifndef SWIFT_USE_SWIFTCALL
-#ifdef __s390x__
+#if __has_attribute(swiftcall) || defined(__linux__)
 #define SWIFT_USE_SWIFTCALL 1
 #else
-#define SWIFT_USE_SWIFTCALL 1
+#define SWIFT_USE_SWIFTCALL 0
 #endif
 #endif
 

stdlib/public/SwiftShims/LibcShims.h

@@ -60,13 +60,13 @@ __swift_size_t _swift_stdlib_fwrite_stdout(const void *ptr, __swift_size_t size,
                                            __swift_size_t nitems);
 
 // String handling <string.h>
-__attribute__((__pure__)) SWIFT_RUNTIME_STDLIB_INTERFACE __swift_size_t
+SWIFT_READONLY SWIFT_RUNTIME_STDLIB_INTERFACE __swift_size_t
 _swift_stdlib_strlen(const char *s);
 
-__attribute__((__pure__)) SWIFT_RUNTIME_STDLIB_INTERFACE __swift_size_t
+SWIFT_READONLY SWIFT_RUNTIME_STDLIB_INTERFACE __swift_size_t
 _swift_stdlib_strlen_unsigned(const unsigned char *s);
 
-__attribute__((__pure__))
+SWIFT_READONLY
 SWIFT_RUNTIME_STDLIB_INTERFACE
 int _swift_stdlib_memcmp(const void *s1, const void *s2, __swift_size_t n);
 
@@ -80,7 +80,7 @@ SWIFT_RUNTIME_STDLIB_INTERFACE
 int _swift_stdlib_close(int fd);
 
 // Non-standard extensions
-__attribute__((__const__)) SWIFT_RUNTIME_STDLIB_INTERFACE __swift_size_t
+SWIFT_READNONE SWIFT_RUNTIME_STDLIB_INTERFACE __swift_size_t
 _swift_stdlib_malloc_size(const void *ptr);
 
 // Random number <random>

stdlib/public/SwiftShims/SwiftStddef.h

@@ -13,7 +13,19 @@
 #ifndef SWIFT_STDLIB_SHIMS_SWIFT_STDDEF_H
 #define SWIFT_STDLIB_SHIMS_SWIFT_STDDEF_H
 
+// stddef.h is provided by Clang, but it dispatches to libc's stddef.h.  As a
+// result, using stddef.h here would pull in Darwin module (which includes
+// libc). This creates a dependency cycle, so we can't use stddef.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.
+#if !defined(__APPLE__) && !defined(__linux__)
+#include <stddef.h>
+typedef size_t __swift_size_t;
+#else
 typedef __SIZE_TYPE__ __swift_size_t;
+#endif
 
 #endif // SWIFT_STDLIB_SHIMS_SWIFT_STDDEF_H
-

stdlib/public/SwiftShims/SwiftStdint.h

@@ -15,12 +15,28 @@
 
 // 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
+// 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__)
+#include <stdint.h>
+typedef int64_t __swift_int64_t;
+typedef uint64_t __swift_uint64_t;
+typedef int32_t __swift_int32_t;
+typedef uint32_t __swift_uint32_t;
+typedef int16_t __swift_int16_t;
+typedef uint16_t __swift_uint16_t;
+typedef int8_t __swift_int8_t;
+typedef uint8_t __swift_uint8_t;
+typedef intptr_t __swift_intptr_t;
+typedef uintptr_t __swift_uintptr_t;
+#else
 typedef __INT64_TYPE__ __swift_int64_t;
 #ifdef __UINT64_TYPE__
 typedef __UINT64_TYPE__ __swift_uint64_t;
@@ -56,6 +72,6 @@ typedef unsigned __INT8_TYPE__ __swift_uint8_t;
 
 typedef __swift_intn_t(__INTPTR_WIDTH__) __swift_intptr_t;
 typedef __swift_uintn_t(__INTPTR_WIDTH__) __swift_uintptr_t;
+#endif
 
 #endif // SWIFT_STDLIB_SHIMS_SWIFT_STDINT_H
-

stdlib/public/SwiftShims/Visibility.h

@@ -19,7 +19,11 @@
 #define SWIFT_STDLIB_SHIMS_VISIBILITY_H
 
 #if !defined(__has_feature)
-#define __has_feature(x) false
+#define __has_feature(x) 0
+#endif
+
+#if !defined(__has_attribute)
+#define __has_attribute(x) 0
 #endif
 
 #if __has_feature(nullability)
@@ -40,6 +44,18 @@
 # define SWIFT_END_NULLABILITY_ANNOTATIONS
 #endif
 
+#if __has_attribute(pure)
+#define SWIFT_READONLY __attribute__((__pure__))
+#else
+#define SWIFT_READONLY
+#endif
+
+#if __has_attribute(const)
+#define SWIFT_READNONE __attribute__((__const__))
+#else
+#define SWIFT_READNONE
+#endif
+
 // TODO: support using shims headers in overlays by parameterizing
 // SWIFT_RUNTIME_EXPORT on the library it's exported from, then setting
 // protected vs. default based on the current value of __SWIFT_CURRENT_DYLIB.

stdlib/public/stubs/Stubs.cpp

@@ -65,6 +65,7 @@ static long double swift_strtold_l(const char *nptr,
 #endif
 #include <limits>
 #include "llvm/ADT/StringExtras.h"
+#include "llvm/Support/Compiler.h"
 #include "swift/Runtime/Debug.h"
 #include "swift/Basic/Lazy.h"
 
@@ -394,7 +395,13 @@ __muloti4(ti_int a, ti_int b, int* overflow)
 // some other lower-level architecture issue that I'm
 // missing.  Perhaps relevant bug report:
 // FIXME: https://llvm.org/bugs/show_bug.cgi?id=14469
-typedef int di_int __attribute__((__mode__(DI)));
+#if __has_attribute(__mode__(DI))
+#define SWIFT_MODE_DI __attribute__((__mode__(DI)))
+#else
+#define SWIFT_MODE_DI
+#endif
+
+typedef int di_int SWIFT_MODE_DI;
 SWIFT_RUNTIME_STDLIB_INTERFACE
 di_int
 __mulodi4(di_int a, di_int b, int* overflow)