Due to the custom build system implemented in CMake for Swift, we cannot
properly detect the target and set flags appropriately. Instead, assume
that if the primary variant is an Apple target, that all targets are
Apple variants. This fixes cross-compilation on macOS.
These would never be decoded in normal use, but it's possible to construct an archive that will attempt to decode them. Without this override, that throws an exception or worse.
rdar://problem/48429185
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.
These are supposed to be processed in the C locale always, irrespective
of the current locale. We were not doing this and so we would parse the
value incorrectly.
Old Swift and new Swift runtimes and overlays need to coexist in the same process. This means there must not be any classes which have the same ObjC runtime name in old and new, because the ObjC runtime doesn't like name collisions.
When possible without breaking source compatibility, classes were renamed in Swift, which results in a different ObjC name.
Public classes were renamed only on the ObjC side using the @_objcRuntimeName attribute.
This is similar to the work done in pull request #19295. That only renamed @objc classes. This renames all of the others, since even pure Swift classes still get an ObjC name.
rdar://problem/46646438
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 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.
This implements commandline access on Windows by using the Windows Shell
API to access the commandline information and making it available in
Swift. This is needed for the correct invocation of the child process
in the unit tests.
• 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
Previously, the stdlib provided:
- getters for AnyKeyPath and PartialKeyPath, which have remained;
- a getter for KeyPath, which still exists alongside a new read
coroutine; and
- a pair of owned mutable addressors that provided modify-like behavior
for WritableKeyPath and ReferenceWritableKeyPath, which have been
replaced with modify coroutines and augmented with dedicated setters.
SILGen then uses the most efficient accessor available for the access
it's been asked to do: for example, if it's been asked to produce a
borrowed r-value, it uses the read accessor.
Providing a broad spectrum of accessor functions here seems acceptable
because the code-size hit is fixed-size: we don't need to generate
extra code per storage declaration to support more alternatives for
key paths.
Note that this is just the compiler ABI; the implementation is still
basically what it was. That means the implementation of the setters
and the read accessor is pretty far from optimal. But we can improve
the implementation later; we can't improve the ABI.
The coroutine accessors have to be implemented in C++ and used via
hand-rolled declarations in SILGen because it's not currently possible
to declare independent coroutine accessors in Swift.
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
After rebasing on master and incorporating more 32-bit support,
perform a bunch of cleanup, documentation updates, comments, move code
back to String declaration, etc.
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.
`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.
On Windows the filesystem is not case sensitive and this will link just fine.
However, the Windows SDK provides the import library with the lowercase name.
Adjust the name so that the link actually succeeds on case-sensitive file
systems (like on Linux). This fixes the Windows cross-compile.
The system header depends on Windows.h but does not include it itself. This
results in base Windows types (e.g. ULONG) to be undefined. Include the header
to include the needed typedefs.
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
Instead of only requiring Glibc's implementation of getrandom, try to use a direct syscall to getrandom. This should allow more versions of linux to utilize getrandom instead of always having to fallback to reading /dev/urandom.
- Don’t expose the raw execution seed to _rawHashValue.
- Change the type of _rawHashValue’s seed from (UInt64,UInt64) to a single Int. Working with a pair of UInt64s is unwieldy, and overkill in practice. Int as a seed also integrates nicely with Int as a hash value.
- Remove _HasherCore._generateSeed(). Instead, simply call finalize() on a copy of the hasher to get a seed suitable for _rawHashValue.
- Update Set and Dictionary to store a single Int as the seed value.
Note that this doesn’t affect the core hasher, which still mixes in the actual 128-bit execution seed during its initialization. To reduce the potential of confusion, use the name “rawSeed” to refer to an actual 128-bit seed value.
Due to the build ordering, I didn't notice this earlier. The inclusion
of the header would define the guard, preventing the needed definitions.
Unconditionally define the functions to ensure that they are available.
- Use _HashTable to unify low-level hashing operations across Set and Dictionary.
- Store the capacity directly inside the storage header. This allows the maximum load factor to be controlled by non-inlinable code.
- Introduce a dedicated class for the empty singleton.
- Add _BridgingHashBuffer, a standalone flat hash buffer for use in deferred bridging. Use it to eliminate the need to support non-hashable storage/wrapper variants and to improve memory use in cases where Key or Value are verbatim bridged.
- Eliminate the “TypedNative*Storage” class and _NativeSet/_NativeDictionary’s support for non-hashable keys.
- Rename storage classes as follows:
_RawNativeSetStorage ⟹ _RawSetStorage
_RawNativeDictionaryStorage ⟹ _RawDictionaryStorage
_TypedNativeSetStorage ⟹ (removed)
_TypedNativeDictionaryStorage ⟹ (removed)
_HashableTypedNativeSetStorage ⟹ _SetStorage
_HashableTypedNativeDictionaryStorage ⟹ _DictionaryStorage
The new names make it obvious which ivar layout is in use.
This allows us to move the empty NSSet/NSDictionary overrides out of the root storage class; they don’t really belong there. More importantly, it makes empty sets/dictionaries super obvious to lldb and other runtime tools.
