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.
CMake supports the notion of installation components. Right now we have some
custom code for supporting swift components. I think that for installation
purposes, it would be nice to use the CMake component system.
This should be a non-functional change. We should still only be generating
install rules for targets and files in components we want to install, and we
still use the install ninja target to install everything.
This implements the protocols and static functions proposed in SE-0246, plus some initial test coverage. It also has some rough accompanying cleanup of tgmath. It does not include the globals (on scalars or SIMD types) nor does it deprecate much in tgmath.h.
_swift_stdlib_getHardwareConcurrency's declaration isn't a proper prototype:
it's missing `void` inside the brackets.
Found while compiling the stdlib to WebAssembly, which fails with:
Functions with 'no-prototype' attribute must take varargs: _swift_stdlib_getHardwareConcurrency
This shouldn't impact existing platforms.
* Revert "Merge pull request #23791 from compnerd/you-know-nothing-clang"
This reverts commit 5150981150, reversing
changes made to 8fc305c03e.
* Revert "Merge pull request #23780 from compnerd/math-is-terrible"
This reverts commit 2d7fedd25f, reversing
changes made to 0205150b8f.
* Revert "Merge pull request #23140 from stephentyrone/mafs"
This reverts commit 777750dc51, reversing
changes made to 0c8920e747.
Since we use `_hypotf` on Windows rather than `__builtin_hyptof` due to
a bug in LLVM with the TLI lowering to the wrong builtin, include the
math header to get the proper declaration.
This commit implements SE-0246, by adding conformance to Real to the Float, CGFloat, Double, and Float80 types, implemented either in terms of the system's C math library, existing standard library functionality, or LLVM intrinsics. It includes basic test coverage for these new functions, and deprecates and obsoletes *some* existing functionality in the Platform overlay. We still need to make a decision about how to handle the remaining "tgmath" functions, because obsoleting them is technically a source-breaking change (if users have unqualified names like "exp(1)", it's fine, but it would break users who have used qualified names like "Darwin.exp(1)".)
