Reviewed the cases of Glibc where branching occurred and checked the
skipped headers against the Android NDK sysroot, and added the Android
check in the right places. This will give access to a lot more
functions from libc.
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.
* 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.
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)".)
Fundamental decision to be made; should implementation hooks present like `Float.exp(_ x: Float) -> Float` or like `Float.Maths.exp(_ x: Float) -> Float`? Having the intermediate namespace to group them as in the second is definitely nicer, but it requires a little bit of extra machinery, and much more importantly, there doesn't seem to be any way to make access to the static `Maths` associatedtype transparent.
Magic symbols of the form $ld$install_name$os9.0$@rpath/libswiftCore.dylib tell the linker to use that install name when targeting that OS version. Use these symbols to specify an @rpath install name for all back-deployment libraries when targeting watchOS 2.0-5.1, iOS 7.0-12.1, and macOS 10.9-10.14.
rdar://problem/45027809
This avoids us having to pattern match every source file which should
help speed up the CMake generation. A secondary optimization is
possible with CMake 3.14 which has the ability to remove the last
extension component without having to resort to regular expressions. It
also helps easily identify the GYB'ed sources.
Because Microsoft inlines the definitions of the printf family of
functions, we end up with undefined references to them. Add an explicit
request to link against the `legacy_stdio_definitions` library when
`ucrt.C.stdio` is used which provides out-of-line definitions for them.
This fixes the building of the `stdlib/VarArgs' test.
Split out the User32 interfaces from the previously owning module
(WinSock2). This improves the debugging experience and more accurately
reflects the module structure but should not impact the ability to build
the swift runtime.
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
Although technically these shouldn't be needed on Windows since there is
no compatibility to maintain since there is no version that exists
previously. However, this will ease porting of sources to the platform.
It also ensures that future tests added cover windows as well.
Additional APISets are required to implement the Foundation API surface.
Expand the module to include that. Unfortunately, I have not been able
to get the ImageHelp or the DebugHelp APIs or the RTLSupport APISet
covered under the module. Those are required to get stack captures to
work.
This ensures that we do not allow someone to import `_setjmp` on Windows
which is not annotated with `__attribute__((__returns_twice__))` and
cannot be adjusted without assistance from Microsoft.
Since `stdin`, `stdout`, and `stderr` are defined via macros, we cannot see them
on the swift side. Replicate these by hand. Expose `STDIN_FILENO`,
`STDOUT_FILENO`, and `STDERR_FILENO` for compatibility with other libc
implementations. This reduces the need for changing the codebase unnecessarily
for MSVCRT.
Add the setjmp module which was missing. The roughly equivalent
function is `_setjmp`. Unfortunately, it is not marked as
`__attribute__((__returns_twice__))`.
Unlike Darwin, on Linux when using functions from math.h the m library
needs to be added to the compilation. This should be explicit in the
module map, rather than being implicit in the driver.
Fixes SR-9198
The key thing here is that all of the underlying code is exactly the same. I
purposely did not debride anything. This is to ensure that I am not touching too
much and increasing the probability of weird errors from occurring. Thus the
exact same code should be executed... just the routing changed.
Android Bionic offers lgammaf_r and lgamma_r only if _GNU_SOURCE is
provided. It also offers lgammal_r in API levels 23 and above, but
that one will not be available until 128 bit floats are supported.
The patch modifies the importer to use _GNU_SOURCE while importing
Android headers and slighly modify a check that was avoding the
function from being created for Android.
This fixes the compilation of the tgmath test in Android.
The functions in LibcShims are used externally, some directly and some through @inlineable functions. These are changed to SWIFT_RUNTIME_STDLIB_SPI to better match their actual usage. Their names are also changed to add "_swift" to the front to match our naming conventions.
Three functions from SwiftObject.mm are changed to SPI and get a _swift prefix.
A few other support functions are also changed to SPI. They already had a prefix and look like they were meant to be SPI anyway. It was just hard to notice any mixup when they were #defined to the same thing.
rdar://problem/35863717
* Make FloatingPoint require that Self.Magnitude == Self
We didn't have the where clause to express this constraint at the time that the FloatingPoint protocol was implemented, but we do now. This is not a semantic change to FloatingPoint, which has always bound IEEE-754 arithmetic types, for which this constraint would necessarily hold, but it does effect the type system.
For example, currently the following function does not type check:
~~~~
func foo<T>(x: T) -> T where T: FloatingPoint {
var r = x.remainder(dividingBy: 1)
return r.magnitude
}
~~~~
with this change, it compiles correctly.
Having done this, we no longer need to have a separate `abs` defined on FloatingPoint; we can use the existing function defined on `SignedNumeric` instead. Additionally mark the global `fabs` defined in the platform C module deprecated in favor of the Swift `abs`; we don't need to carry two names for this function going forward.
