* 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.
ndk14 introduced "unified headers" which merged the headers for all
different API versions into one directory which effectively split the
"SWIFT_SDK_ANDROID_ARCH_${ARCH}_PATH" into two different directories.
Add include and library specific paths to various compilation and link
invocations across the Swift project to account for this change. Remove
some broken sysroot/sdk specific settings.
Add the `vadefs` and `stdint` submodules. These are required to get the
importing of the standard types (`intmax_t` and `uintptr_t`) correct
with the Visual C runtime. This allows building the libdispatch Swift
overlay.
Cross-compilation for multiple architectures & sdks require various
variables to be split to specify the arch/adk variant being focused on.
This change modifies various uses of the `SWIFT_SDK_${SDK}_PATH` to
`SWIFT_SDK_${SDK}_ARCH_${ARCH}`
In theory there could be a "fixed-layout" enum that's not exhaustive
but promises not to add any more cases with payloads, but we don't
need that distinction today.
(Note that @objc enums are still "fixed-layout" in the actual sense of
"having a compile-time known layout". There's just no special way to
spell that.)
* Updates to tgmath functions for CGFloat
These changes bring CGFloat in line with the other FloatingPoint types. Some of this stuff is now defined at the protocol level, so we can get rid of it at the concrete type level. A couple other functions have been deprecated for all types, with protocol or tgmath replacements.
* Cleanup tgmath wrappers.
- Remove special-case gyb logic for lgamma on Darwin; the symbols we need are always present, even if not visible in the headers, so we only need a prototype.
- Add some deprecations for symbols that have direct stdlib analogues.
- Make some operations generic on [Binary]FloatingPoint, where they can map to the protocols instead of calling libm.
- Mark ldexp(Float/Double) renamed to scalbn; for binary formats these are identical functions, and we don't really want to use these names for hypothetical future Decimal support, as they're not Swifty.
