* Dynamic Cast Rework: Runtime
This is a completely refactored version of the core swift_dynamicCast
runtime method.
This fixes a number of bugs, especially in the handling of multiply-wrapped
types such as Optional within Any. The result should be much closer to the
behavior specified by `docs/DynamicCasting.md`.
Most of the type-specific logic is simply copied over from the
earlier implementation, but the overall structure has been changed
to be uniformly recursive. In particular, this provides uniform
handling of Optional, existentials, Any and other common "box"
types along all paths. The consistent structure should also be
easier to update in the future with new general types.
Benchmarking does not show any noticable performance implications.
**Temporarily**, the old implementation is still available. Setting the
environment variable `SWIFT_OLD_DYNAMIC_CAST_RUNTIME` before launching a program
will use the old runtime implementation. This is only to facilitate testing;
once the new implementation is stable, I expect to completely remove the old
implementation.
We're using a lot of space on the free lists. Each vector is three words, and we have two of them. Switch to a single linked list. We only need one list, as both kinds of pointers just get free()'d. A linked list optimizes for the common case where the list is empty. This takes us from six words to one.
Also make ReaderCount, ElementCount, and ElementCapacity uint32_ts. The size_ts were unnecessarily large and this saves some space on 64-bit systems.
While we're in there, add 0/NULL initialization to all elements. The current use in the runtime is unaffected (it's statically allocated) but the local variables used in the test were tripping over this.
This specific check has never worked on all processors (because
some FP HW mangles NaNs) and recent LLVM changes have broken
it on the remaining platforms.
Resolves SR-13354
We can't actually check for NaN (because the notion doesn't exist for Comparable), but we can require that the endpoint is non-exceptional by checking if it equals itself.
The conversion of the naonseconds to Mach ticks in multiples of Mach
timebase units alters the time. This would fail on ASi where mach ticks
are not synonymous with nanoseconds.
Swap the parameters in `assertEqual` to improve diagnostics on failure.
This now prints as:
```
stdout>>> expected: -431 (of type Swift.int)
stdout>>> actual: -11 (of type Swift.int)
```
The experimental concurrency model will require a supporting runtime
and possibly end-user-visible library constructs. Introduce a stub of
such a library, enabled by a new `build-script` option
`--enable-experimental-concurrency`, so we have a place to put this
work.
Optimize the unconditional_checked_cast_addr in this pattern:
%box = alloc_existential_box $Error, $ConcreteError
%a = project_existential_box $ConcreteError in %b : $Error
store %value to %a : $*ConcreteError
%err = alloc_stack $Error
store %box to %err : $*Error
%dest = alloc_stack $ConcreteError
unconditional_checked_cast_addr Error in %err : $*Error to ConcreteError in %dest : $*ConcreteError
to:
...
retain_value %value : $ConcreteError
destroy_addr %err : $*Error
store %value to %dest $*ConcreteError
This lets the alloc_existential_box become dead and it can be removed in following optimizations.
The same optimization is also done for conditional_checked_cast_addr.
There is also an implication for debugging:
Each "throw" in the code calls the runtime function swift_willThrow. The function is used by the debugger to set a breakpoint and also add hooks.
This optimization can completely eliminate a "throw", including the runtime call.
So, with optimized code, the user might not see the program to break at a throw, whereas in the source code it is actually throwing.
On the other hand, eliminating the existential box is a significant performance win and we don't guarantee any debugging behavior for optimized code anyway. So I think this is a reasonable trade-off.
I added an option "-Xllvm -keep-will-throw-call" to keep the runtime call which can be used if someone want's to reliably break on "throw" in optimized builds.
rdar://problem/66055678
Add `async` to the type system. `async` can be written as part of a
function type or function declaration, following the parameter list, e.g.,
func doSomeWork() async { ... }
`async` functions are distinct from non-`async` functions and there
are no conversions amongst them. At present, `async` functions do not
*do* anything, but this commit fully supports them as a distinct kind
of function throughout:
* Parsing of `async`
* AST representation of `async` in declarations and types
* Syntactic type representation of `async`
* (De-/re-)mangling of function types involving 'async'
* Runtime type representation and reconstruction of function types
involving `async`.
* Dynamic casting restrictions for `async` function types
* (De-)serialization of `async` function types
* Disabling overriding, witness matching, and conversions with
differing `async`
Optimizes String operations with constant operands.
Specifically:
* Replaces x.append(y) with x = y if x is empty.
* Removes x.append("")
* Replaces x.append(y) with x = x + y if x and y are constant strings.
* Replaces _typeName(T.self) with a constant string if T is statically known.
With this optimization it's possible to constant fold string interpolations, like "the \(Int.self) type" -> "the Int type"
This new pass runs on high-level SIL, where semantic calls are still in place.
rdar://problem/65642843
LLVM doesn't have a stable ABI for Float16 on x86 yet; we're working with Intel to get that fixed, but we don't want to make the type available on macOS until a stable ABI is actually available, because we'd break binaries compiled before any calling convention changes if we do.
This function walks all the fields of a struct, class, or tuple, and calls
`body` with the name, offset, and type of each field. `body` can perform
any required work or validation, returning `true` to continue walking fields
or `false` to stop immediately.
Adjust the division operation to ensure that we get an integral value
back. Without this, we would attempt to shift a floating point value
by bitwise operations which is not supported.
Most of the changes fall into a few categories:
* Replace explicit "x86_64" with %target-cpu in lit tests
* Cope with architecture differences in IR/asm/etc. macOS-specific tests
* SR-12486: `T.self is Any.Protocol` is broken
This turned out to be fallout from https://github.com/apple/swift/pull/27572
which was in turn motivated by our confusing metatype syntax when generic variables are bound to protocols.
In particular, the earlier PR was an attempt to make the expression
`x is T.Type` (where `T` is a generic type variable bound to a protocol `P`)
behave the same as
`x is P.Type` (where `P` is a protocol).
Unfortunately, the generic `T.Type` actually binds to `P.Protocol` in this case (not `P.Type`), so the original motivation was flawed, and as it happens, `x is T.Type` already behaved the same as `x is P.Protocol` in this situation.
This PR reverts that earlier change and beefs up some of the tests around these behaviors.
Resolves SR-12486
Resolves rdar://62201613
Reverts PR#27572
Clean up a few general patterns that are now obviated by canImport
This aligns more generally with the cleanup that the Swift Package
Manager has already done in their automated XCTest-plumbing tool in
apple/swift-package-manager#1826.
