In the prior revision, this file combined two approaches:
- the old approach of doing some fun things with arrays and hoping
that any important public and internal generic symbols will happen
to be specialized
- the new approach of explicitly specializing a generic symbol by
annotating a dummy "proxy" function with the actual generic mangled
name, then calling that proxy with an argument of the type to be
specialized.
Unfortunately, the symbols exposed by SwiftOnoneSupport have become
ABI. Therefore, the old approach can break over time because changes
to the compiler and standard library will affect which symbols happen
to be specialized. It can be extremely difficult to debug why those
symbols have gone missing.
The new approach will work to ensure ABI stability, but the
implementation was incomplete and the style of implementation would
not work in many cases. It was still relying on the old approach to
cover the generic symbols that weren't explicitly specialized. Also,
it wasn't clear to anyone reading the source what specializations of
those generic symbols are intended and required by the ABI.
This commit completely removes the old approach to prespecialization.
All generic symbols required by the ABI are now explicitly listed.
There are now several different proxy functions declared as methods
within the generic type that they represent. The parameter types of
each proxy function now match the parameter types of the generic
function. This guarantees that the compiler can correctly apply the
proxy function's subsitution map to the generic function's generic
signature. For example, it now handles subtitution of dependent types
(like Range<T>), substitutions that are not in the first parameter
position, and subsitition that occur in multiple parameters.
The proxy functions are now directly invoked with the concrete
argument type needed for specialization. There's no other incidental
code.
It is now possible to read this source and understand which standard
library functions need to be prespecialized on which types.
_swift_stdlib_getHardwareConcurrency's declaration isn't a proper prototype:
it's missing `void` inside the brackets.
Found while compiling the stdlib to WebAssembly, which fails with:
Functions with 'no-prototype' attribute must take varargs: _swift_stdlib_getHardwareConcurrency
This shouldn't impact existing platforms.
The `ObjectIdentifier(object as AnyObject)` is not necessarily stable; this breaks reflexivity for ==, and it makes the hash encoding nondeterministic.
These are triggering a bad compile-time regression for some expressions; that's a bug that should be fixed, but we don't know how to fix it yet, so we'll need to remove these in the short-term, and possibly spell them differently in the medium term.
The purpose of this module is to prespecialize generic methods in the
stdlib. All symbols exposed by the ABI must be explicitly identified
to maintain ABI compatibility. Some of those ABI-exposed symbols
reference internal stdlib types.
Given that we want the prespecialized code to live in the separate
SwiftOnoneSupport library, and we want the module to explicitly list
all the symbols required for ABI stability, there's no way around
disabling access control when building it. In fact, that flag does
precisely what we want.
This should be harmless because
- no one imports SwiftOnoneSupport.swiftmodule
- these internal symbols were always being exposed in
SwiftOnoneSupport.dylib, so nothing changes there
* Additions to SIMD types.
- extension from 2 and 3-element vectors to 3- and 4-element vectors.
- the .one member
- swizzles via subscript-by-simd
- min/max/sum reductions
- min/max/clamp on vectors-of-comparable
- any and all
- Make permute subscript wrap on vector length, even for SIMD3 dictionaries. Also restore min/max to globals, rather than static functions.
The sections to which the start/stop symbols are being applied do not
guarantee pointer alignment. In particular, the field metadata is
aligned to a 4-byte boundary, which is less then the pointer alignment
of `uintptr_t`. This results in extra padding in the data which is
going to cause the iteration to run off the end. A similar byte
alignment is forced for the markers in the ELF case as well. This fixes
one of the reflection tests on Windows where we were attempting to
decode the padding as an entry.
