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 conversion routines in MSVCPRT return "0" for the conversion of
"-inf" et al. Provde template specializations for `float`, `double`,
and `long double` to use `strtof`, `strtod`, and `strtold` respectively.
This fixes the lossless conversion of floating point constants.
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 mapping of the return value of the `FlsAlloc` was flipped resulting
in the failure of the TLS key creation. The test suite would fail to
generate the TLS key resulting in failures.
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.
The swift variables use the upper case spelling while CMake uses mixed
case. Use the correct case to fix the build. This is preferable to
using MATCH to avoid the unnecessary configure time penalties.
Since handle's are so common place on Windows and the clang importer cannot
import the complex macro for INVALID_HANDLE_VALUE, define it locally to provide
an easier path to writing swift code on Windows. This repairs the Windows
builds.
We were creating a local Demangler instance, demangling a type name
using it, and then returning one of the resulting nodes to the caller.
Fixes rdar://problem/46817009.
Assume that the build currently targets only a single target. Use the target to
determine the linked libraries for the target library (swiftCore). This is more
precise and more importantly, is required to enable cross-compilation of various
targets.
We are now using Shell APIs for the command line parsing. Ensure that we link
against the Shell32 library. This is needed for the cross-compilation as on
Windows, the environment will set a default link against a number of libraries.
This is more precise and explicit.
We need to explicity ensure that an integer is in the required byte
order (little-endian in this case) before accessing it as an array
of bytes through an unsafe pointer.
Anonymous context descriptors were being treated as non-generic by
IRGen, which lead to problems for (file)private types within generic
types. Emit generic parameters and requirements for anonymous contexts
as well.
The runtime was mostly prepared for this, and the ABI already
accounted for it, so the runtime change is minor---it only affected
building a demangle tree from metadata.
Fixes rdar://problem/46853806.
Removes the _getBuiltinLogicValue intrinsic in favor of an open-coded
struct_extract in SIL. This removes Sema's last non-literal use of builtin
integer types and unblocks a bunch of cleanup.
This patch would be NFC, but it improves line information for conditional expression codegen.
In anticipation of potential future HW features, e.g. armv8.5 memory
tagging, only use the high 4 bytes as discriminator bits in
_BridgeObject rather than the top 8 bits. Utilize two perf flags to
cover this instead. This requires shifting around a fair amount of
internal complexity.
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.
Remove Discriminator, Flags, etc., abstractions from
StringObject. These cause code divergence between 32-bit and 64-bit
ABI, complicate ABI changes, and otherwise contribute to bloat.
Turns out some people used this type despite it being prefixed with
`_stdlib_`, so we have to keep it, with an obsoletion message this time.
Second copy of the same type is kept available past Swift 5 in
SwiftPrivate for use in tests.
Moving them out to SIMDOperators didn't help, but the type checker hack
might. Move them back into the Swift standard library where they belong,
but leave SIMDOperators there to smooth over any short-term
incompatibilities.
