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)".)
Update the shims logic to make sure that it works for Xcode as well.
Rather than adding additional rules, just simplify it down to the one
canonical way in modern LLVM land. The headers are always installed to
the LLVM_LIBRARY_OUTPUT_INTDIR which will be defined for us in both the
standalone and unified build mode. This allows us to just remove all
the work to find the headers since they will always be in one location.
The assertions here are based around the idea that `std::atomic` is
trivially constructible which is not a guarantee that the standard fully
provides. The default initialization of the `std::atomic` type may
leave it in an undetermined state. These were caught using the Visual
C++ preview runtime.
Ideally, the object constructor would use a placement new operator.
However, prior to C++17, the C++ standard mandated that there be a
NULL pointer check in the placement new operator. This is something
which is no longer the case with C++17. Switch to the placement new
operator for C++17 and newer and enable that codepath for Windows as
well (which seemingly elides the null-pointer check with clang-cl).
Rather than directly using the extension `__builtin_expect`, use a macro
to permit the removal of the builtin on compilers which do not support
this (i.e. cl). This permits us to build the swift compiler with MSVC
again.
Unfortunately, `cl` does not support C11. Guard the `_Generic` approach and in
C++ mode use `std::make_signed`. Thanks to Jordan Rose for the reminder about
the type_traits helper!
They're all the same anyway, and no longer even need to be compiled,
just copied in as text.
And drastically simplify how we "generate" them. Instead of attaching
their build jobs to the appropriate overlays, if present, "just" have
one job to copy them all and attach it to the Darwin overlay. That's
what we do for the overlay shim headers, and it's good enough.
(Eventually we want to get out of the business of shipping them
altogether.)
This does have the same flaw as the shim headers: if you /just/ change
API notes, the corresponding overlay does not get rebuilt. You have to
touch that too. But in practice that'll happen most of the time
anyway.
Part of rdar://problem/43545560
This fixes the Windows platform, where the aligned allocation path is
not malloc-compatible. It won't have any observable difference on
Darwin or Linux, aside from manually allocated memory on Linux now
being consistently 16-byte aligned (heap objects will still be 8-byte
aligned on Linux).
It is unfortunate that we can't guarantee Swift-allocated memory via
Unsafe*Pointer is malloc compatible on Windows. It would have been
nice for that to be a cross platform guarantee since it's normal to
allocate in C and deallocate in Swift or vice-versa. Now we have to
tell developers to always use _aligned_malloc/_aligned_free when
transitioning between Swift/C if they expect their code to work on
Windows.
Even though this fix isn't required today on Darwin/Linux, it makes
good sense to guarantee that the allocation/deallocation paths are
consistent.
This is done by specifying a constant that stdlib can use to round up
alignment, _swift_MinAllocationAlignment. The runtime asserts that
this constant is greater than MALLOC_ALIGN_MASK for all platforms.
This way, manually allocated buffers will always use the aligned
allocation path. If users specify an alignment less than m
round up so users don't need
to pass the same alignment to deallocate the buffer). This constant
does not need to be ABI.
Alternatives are:
1. Require users of Unsafe*Pointer to specify the same alignment
during deallocation. This is obviously madness.
2. Introduce new runtime entry points:
swift_alignedAlloc/swift_alignedDealloc, introduce corresponding
new builtins, and have Unsafe*Pointer always call those. This would
make the runtime API a little more obvious but would introduce
complexity in other areas of the compiler and it doesn't have any
other significant benefit. Less than 16-byte alignment of manually
allocated buffers on Linux is a non-goal.
This converts the path separators to the CMake way. This is primarily
important for Windows where the path separator is \ rather than /. This
conversion allows the specification of the path in the proper windows
path style.
The inclusion of Windows.h would cause the Shims to depend on WinSDK, which
would in turn depend on MSVCRT. However, the SwiftShims are using in MSVCRT
causing a circular dependency between WinSDK and MSVCRT preventing a clean build
from succeeding. Break the dependency by only including libc headers in the
shims header.
The SDK directory is now confusing as the Windows target also has a SDK
overlay. In order to make this more uniform, move the SDK directory to
Darwin which covers the fact that this covers the XNU family of OSes.
The Windows directory contains the SDK overlay for the Windows target.
• Convert _AbstractStringStorage to a protocol, and the free functions used to deduplicate implementations to extensions on that protocol.
• Move 'start' into the abstract type and use that to simplify some code
• Move the ASCII fast path for length into UTF16View.
• Add a weirder but faster way to check which (if any) of our NSString subclasses a given object is, and adopt it
Define a generic 64-bit address space ABI which is capped at 56
bits. Switch ppc64 and s390x over to it.
This also allows String to have (roughly) the same representation
across 64-bit platforms.
Revert #20194, which seems to be more trouble than it's worth. Instead, move the functions that SwiftPrivate needs back into LibcShims.h/cpp as SPI.
rdar://problem/45817565
Use relative references instead of pointers so that the pattern can be true-const. Instead of trying
to instantiate a constant key path literal in-place, point to a cache variable that we can store
a pointer to the shared instance into when instantiated. Now that the pattern format has diverged
significantly from the instance format, simplify and refactor the instantiation code using a walker
for the pattern format instead of trying to reuse the code for working with instantiated instances.
rdar://problem/42674576
Adjust the block type to use `intptr_t` which is a register-wide integral type.
This allows the same declaration to be portable across LP64 and LLP64
environents.
Otherwise, we return in the autorelease pool and this can keep the block
alive longer than a surrounding withoutActuallyEscaping expression
causing verification failures.
rdar://45226617
SR-8955
[Runtime] Fix swift_retainCount for deiniting objects and BridgeObject tagged values. Make swift_bridgeObjectRetain/Release bail out early for tagged values.
The Allocations Instrument overrides swift_retain with a function that records the retain count by calling swift_retainCount. Its assert for bits.getIsDeiniting() is incorrect in that case, so remove it.
The recent change to ObjC tagged pointer bits on x86-64 also caused the various bridgeObjectRetain/Release functions to call through to swift_retain for BridgeObject tagged values on Mac. swift_retain ignored those values so there was no functional change, except when Instruments overrode it and passed them to swift_retainCount, which tried to dereference them and crashed. Modify bridgeObjectRetain/Release to bail out early again. Also modify swift_retainCount to ignore those values in case anything else expects retainCount to work on any pointer swift_retain accepts.
rdar://problem/45102538
`malloc_usable_size` is provided on Android with API Level 17 or newer.
However, the signature between bionic and glibc is slightly different, with
android marking the parameter as `const`. This results in a type mismatch error
when building the standard library for android. Adjust it to match the target
system.
`ssize_t` is not universally available as it is not a standard type.
However, we require clang to build the runtime due to custom calling
convention support. As a result, we know that the compiler will support
the `_Generic` keyword from the C11 standard. Use this with an
expansion to map the type appropriately for all targets. This avoids
having to have a sanity check in the runtime that the type definition
matches the underlying system.
