* 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)".)
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.
