Static read-only arrays didn't work when passed to ObjectiveC as NSArray.
The storage class of static read-only arrays doesn't carry information about the Element type.
The new `__SwiftDeferredStaticNSArray` is generic over the element type and doesn't have to rely on the element type information of the array storage.
rdar://94185998
The alias defined here with the `.set` directive doesn't actually define a symbolic alias
that the linker respects in all cases. The resulting standard library dylib _does_ contain a
reference to the aliased symbol with the correct value, but the resulting variable is not actually
considered relocatable by the linker. Thus, its value may not always get fixed up properly.
Work around this by dropping the alias for now - directly use the type metadata for Swift.__EmptyArrayStorage
instead.
rdar://100288247
This replaces a number of `#include`-s like this:
```
#include "../../../stdlib/public/SwiftShims/Visibility.h"
```
with this:
```
#include "swift/shims/Visibility.h"
```
This is needed to allow SwiftCompilerSources to use C++ headers which include SwiftShims headers. Currently trying to do that results in errors:
```
swift/swift/include/swift/Demangling/../../../stdlib/public/SwiftShims/module.modulemap:1:8: error: redefinition of module 'SwiftShims'
module SwiftShims {
^
Builds.noindex/swift/swift/bootstrapping0/lib/swift/shims/module.modulemap:1:8: note: previously defined here
module SwiftShims {
^
```
This happens because the headers in both the source dir and the build dir refer to SwiftShims headers by relative path, and both the source root and the build root contain SwiftShims headers (which are equivalent, but since they are located in different dirs, Clang treats them as different modules).
* `__swiftImmortalRefCount`: The bit pattern of the ref-count field of immortal objects
* `__swiftStaticArrayMetadata`: The metadata used for static arrays.
This removes the explicit tree structure reference in the stubs to
locate the shims. Instead, it expects that the `SwiftShims` directory
will be added to the header search path.
Most SwiftShims were put in the swift namespace in C++ mode which broke certain things when importing them in a swift file in C++ mode. This was OK when they were only imported as part of the swift runtime but, now they are used in C++ mode both in the swift runtime and when C++ interop is enabled.
This broke when C++ interop was enabled because the `Swift` module contains references to symbols in the SwiftShims headers which are built without C++ interop enabled (no "swift" namespace). But, when C++ interop is enabled, the SwiftShims headers would put everything in the swift namespace meaning the symbols couldn't be found in the global namespace. Then, the compiler would error when trying to deserialize the Swift module.
There are a few environment variables used to enable debugging options in the
runtime, and we'll likely add more over time. These are implemented with
scattered getenv() calls at the point of use. This is inefficient, as most/all
OSes have to do a linear scan of the environment for each call. It's also not
discoverable, since the only way to find these variables is to inspect the
source.
This commit places all of these variables in a central location.
stdlib/public/runtime/EnvironmentVariables.def defines all of the debug
variables including their name, type, default value, and a help string. On OSes
which make an `environ` array available, the entire array is scanned in a single
pass the first time any debug variable is requested. By quickly rejecting
variables that do not start with `SWIFT_`, we optimize for the common case where
no debug variables are set. We also have a fallback to repeated `getenv()` calls
when a full scan is not possible.
Setting `SWIFT_HELP=YES` will print out all available debug variables along with
a brief description of what they do.
This adds a new copy of LLVMSupport into the runtime. This is the final
step before changing the inline namespace for the runtime support. This
will allow us to avoid the ODR violations from the header definitions of
LLVMSupport.
LLVMSupport forked at: 22492eead218ec91d349c8c50439880fbeacf2b7
Changes made to LLVMSupport from that revision:
process.inc forward declares `_beginthreadex` due to compilation issues due to custom flag handling
API changes required that we alter the `Deallocate` routine to account
for the alignment.
This is a temporary state, meant to simplify the process. We do not use
the entire LLVMSupport library and there is no value in keeping the
entire library. Subsequent commits will prune the library to the needs
for the runtime.
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 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
- 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.
- 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.
Having a single initializer function lets us not set a randomized seed in deterministic mode, slightly simplifying the stdlib.
Set related stdlib properties to be always inlined.
- Hash seed randomization can now be disabled by defining the SWIFT_DETERMINISTIC_HASHING environment value with a value of "1".
- The random hash seed is now generated using arc4random, where available. On platforms where it isn't, don't construct std::random_device twice.
- _Hasher._secretKey is renamed _Hashing._seed, with no setter.
- _Hasher._isDeterministic is a new property exposing whether we're running with non-random hashes. (Set/Dictionary will need this information to decide if they're allowed to use per-instance seeding.)
- `_swiftEmpty{Array,Dictionary,Set}Storage` should be marked with `SWIFT_RUNTIME_STDLIB_INTERFACE` so that they can be linked from the standard library implementation.
- Runtime export symbols ought to have protected visibility.
Changes:
* Terminate all namespaces with the correct closing comment.
* Make sure argument names in comments match the corresponding parameter name.
* Remove redundant get() calls on smart pointers.
* Prefer using "override" or "final" instead of "virtual". Remove "virtual" where appropriate.
Provides a new fallback for Process arguments for those instances where we do
not own main (e.g. Frameworks, Objective-C owns main.m or main.c, etc.). This
includes a number of platform-specific specializations of argument grabbing
logic and a new thread-safe interface to Process.unsafeArgv.
main() | _NSGetArgc/_NSGetArgv | /proc/self/cmdline | __argc/__argv
--------|--------------------------|------------------------|---------------
Scripts | OS X, iOS, tvOS, watchOS | Linux, FreeBSD, Cygwin | Windows
For interpreted Swift where we must filter out the arguments we now do so by
loading the standard library and calling into new SPI to override the arguments
that would have been grabbed by the runtime. This implementation completely
subsumes the use of the entry point '_stdlib_didEnterMain' and it will be
removed in a future commit.
...and explicitly mark symbols we export, either for use by executables or for runtime-stdlib interaction. Until the stdlib supports resilience we have to allow programs to link to these SPI symbols.
