This replaces the `LLVM_ATTRIBUTE_ALWAYS_INLINE` with `SWIFT_INLINE`
which is equivalent but namespaced to Swift instead. This reduces the
unnecessary reliance on LLVMSupport.
This removes the GNUC version check as the runtime does require ABI
support which is not present in GCC. Remove the unnecessary check and
simplify the condition by checking the file format that the visibility
attribute is being applied to and limit it to the ones supporting it.
The current version of the Foundation overlay doesn’t use these, but we should still keep them in case a toolchain snapshot build picks up on overlay module from one of the SDKs in Xcode 11.
rdar://62339802
malloc introspection is a platform feature that is unavailable on
OpenBSD. There is no workaround for the feature, so we have to assume
that allocations succeed in allocating exactly the amount of memory
requested, and nothing more.
Here a new mallocSize shim is introduced so the feature check for malloc
introspection is pushed to the shims, rather than using os checks
directly from Swift. Not every use of malloc_size has been converted
yet; ManagedBuffer.swift still remains. However, this module requires
special care to fix, which will be done separately.
This reverts commit 5fd6e98b2f, reversing
changes made to 3aee49d9d0.
Revert "XFAIL test/Interpreter/metadata_access.swift on arm64e"
This reverts commit 8fe216b004.
Revert "XFAIl test on os stdlib bots"
This reverts commit aea5fa4842.
These should hopefully all be uncontroversial, minimal changes to deal
with progressing the build to completion on OpenBSD or addressing minor
portability issues. This is not the full set of changes to get a
successful build; other portability issues will be addressed in future
commits.
Most of this is just adding the relevant clauses to the ifdefs, but of
note in this commit:
* StdlibUnittest.swift: the default conditional in _getOSVersion assumes
an Apple platform, therefore the explicit conditional and the relevant
enums need filling out. The default conditional should be #error, but
we'll fix this in a different commit.
* tgmath.swift.gyb: inexplicably, OpenBSD is missing just lgammal_r.
Tests are updated correspondingly.
* ThreadLocalStorage.h: we use the pthread implementation, so it
seems we should typedef __swift_thread_key_t as pthread_key_t.
However, that's also a tweak for another commit.
Due to some unfortunate interplay between clang and libstdc++, clang was
not able to correctly identify to alignment of PoolRange and
SideTableRefCountBits, causing it to emit library calls instead of
inlining atomic operations. This was fixed by adding the appropriate
alignment to those types. In addition to that the march for the Linux
target was set to 'core2', which is the earliest architecture to support
cx16, which is necessary for the atomic operations on PoolRange.
Use the C++ spelling for the static assertions. This is a C11
extension, but GCC and MSVC both object to the reserved spelling
(`_Static_assert`). Use the compatibility spelling of `static_assert`
on all targets instead.
We want to enable overlays to import their shims as @_implementationOnly, so that the shims disappear from the public interface.
However, this isn’t possible when a shim is called from an @inlinable func, because then the existence (and definition) of the shim needs to be available to all callers of it.
Unfortunately Foundation’s Data has three instances where it calls _SwiftFoundationOverlayShims._withStackOrHeapBuffer within @inlinable code:
- Data.init<S: Sequence>(_: S)
- Data.append<S: Sequence>(contentsOf: S)
- Data.replaceSubrange<C: Collection>(_: Range<Int>, with: C)
Rewrite the first two to write sequence contents directly into the target Data instance (saving a memcpy and possibly a memory allocation).
In replaceSubrange, add fast paths for contiguous collection cases, falling back to a Swift version of _withStackOrHeapBuffer with a 32-byte inline buffer.
The expectation is that this will be an overall speedup in most cases, with the possible exception of replaceSubrange invocations with a large non-contiguous collection.
rdar://58132561
When building swift as a part of LLVM (as opposed to standalone) the components
related to swift headers should explicitly depend on the clang target to produce
those. On LLVM 9 and up, that would be `clang-resource-headers` and on lower
versions it would be `clang-headers`. It is important that we check for
`clang-resource-headers` first because `clang-headers` refers to something
different in LLVM 9 and up.
* Revert "Add availability information to the new Math function protocols (#24187)"
This reverts commit d2f695935f.
* Revert "SE-0246: Protocols and static functions (#23824)"
This reverts commit 57a4553832.
* Expected abi changes.
One additional tweak (setting the scalar-aligned bit on foreign indices) had to be made to avoid a performance regression for long non-ASCII foreign strings.
`RefCount.h` can be included in a C context - e.g. building the
SwiftShims module. Restrict the C++ overloads to the C++ context only.
This partially improves the build for Windows ARM64.
Seems that SwiftShims cannot import some system headers (checked by a
test in test/ParseableInterface/ModuleCache/SystemDependencies). So
adding <android/api-level.h> is not going to work.
The change reproduces the only piece necessary from the header, which is
interpreting that if no __ANDROID_API__ is defined, the level should be
the maximum allowed.
When the header was used in Android, the usage of __ANDROID_API__ was
not set if the compiler wasn't setting it externally. There was a check
for __ANDROID_API__, which defaulted to zero, and so it didn't pass. The
external function definition was not being done, but in C mode, it
didn't matter because implicit functions are allowed. That's not true in
C++ mode, which fails to compile any code that tries to include this
header.
The solution is including android/api-level.h which will define
__ANDROID_API__ to a very high value if it is not defined already (which
is the default behaviour in the NDK).
Unfortunately, `std::atomic` in msvcprt as of 14.21.27702 is broken for
double-width atomics on ARM64. This has been reported to Microsoft and
is going to be fixed in VC++ 2019u3. For the time being, add a partial
template specialisation for the two double-word sized types temporarily
as a workaround. This allows the standard library build to get further.
`-print-resource-dir` is not available with `clang-cl` which is required
for building the standard library for Windows on Windows. Use the
`/clang:-print-resource-dir` spelling instead. This allows us to build
the standalone runtime for Windows on Windows.
When building the standard library standalone with the host compiler, we
do not have the location of the resource dir available to us nor can it
be computed. Use `-print-resource-dir` to query the value from the
compiler and use that. This is needed to cross-compile the standard
library to android from Windows.
