I discovered this as I began to write some Interpreter tests for move only. This
was triggered by SILGen attempting to pass a non-trivial type to StringBuilder
which is generic, so we needed to materialize.
I also discovered a small bug where we were not properly ignoring class_method
in the move only type eliminator. I just folded the small fix + a test for that
into this commit.
Implement casting to and from extended existentials. This is done by slightly generalizing the conditional conformances checking infrastructure.
Unfortunately, casts for reference types and metatypes are unsound because IRGen is peepholing all non-opaque existential conversions with a helper. I’ll disable that in a follow-up.
rdar://92197049
SWIFT_STDLIB_SINGLE_THREADED_RUNTIME is too much of a blunt instrument here.
It covers both the Concurrency runtime and the rest of the runtime, but we'd
like to be able to have e.g. a single-threaded Concurrency runtime while
the rest of the runtime is still thread safe (for instance).
So: rename it to SWIFT_STDLIB_SINGLE_THREADED_CONCURRENCY and make it just
control the Concurrency runtime, then add a SWIFT_STDLIB_THREADING_PACKAGE
setting at the CMake/build-script level, which defines
SWIFT_STDLIB_THREADING_xxx where xxx depends on the chosen threading package.
This is especially useful on systems where there may be a choice of threading
package that you could use.
rdar://90776105
lit.py currently allows any substring of `target_triple` to be used as a
feature in REQUIRES/UNSUPPORTED/XFAIL. This results in various forms of
the OS spread across the tests and is also somewhat confusing since they
aren't actually listed in the available features.
Modify all OS-related features to use the `OS=` version that Swift adds
instead. We can later remove `config.target_triple` so that these don't
the non-OS versions don't work in the first place.
* [IRGen] Return null reference from IRGenFunction::emitUnmanagedAlloc when layout isKnownEmpty
rdar://92418090
This fixes a runtime crash on x86 caused by allocations of size 0, which are later deallocated with swift_deallocObjectImpl, but are missing the object header.
* Fix test compiler arguments
* Add IRGen test case
* Add assert to FixedBoxTypeInfoBase does not get created with known empty layout
The bit twiddling done by this test falls afoul of ptrauth on ARM64e. We don't support pre-stable Swift ABI code on ARM64e anyway, so just disable the test there.
rdar://92469961
Change actor destruction to call swift_deallocClassInstance instead of swift_deallocObject. When ObjC interop is enabled, swift_deallocClassInstance will check the "pure swift deallocation" bit and call into the ObjC runtime to destruct the instance when needed. This is what clears weak references and associated objects.
rdar://91270492
Mandatory copy propagation was primarily a stop-gap until lexcial
lifetimes were implemented. It supposedly made variables lifetimes
more consistent between -O and -Onone builds. Now that lexical
lifetimes are enabled, it is no longer needed for that purpose (and
will never satisfactorily meet that goal anyway).
Mandatory copy propagation may be enabled again later as a -Onone "
optimization. But that requires a more careful audit of the effect on
debug information.
For now, it should be disabled.
When there are same-type constraints involving opaque archetype
parameters and generic parameters of the enclosing environment, a
nested type of an opaque type archetype might in fact refer to
something in the outer environment of the opaque type. Recognize this
case and perform substitutions on such types using the opaque type's
substitutions.
The "regular" CMO is done with the option `-cross-module-optimization`. It's good for performance but can increase code size.
Now, which this change CMO is also done if the option is not given, but in a very conservative way. Only very small functions are serialized and not additional type metadata is kept alive.
rdar://70082202
The current system is based on MetadataCompletionQueueEntry
objects which are allocated and then enqueued on dependencies.
Blocking is achieved using a condition variable associated
with the lock on the appropriate metadata cache. Condition
variables are inherently susceptible to priority inversions
because the waiting threads have no dynamic knowledge of
which thread will notify the condition. In the current system,
threads that unblock dependencies synchronously advance their
dependent metadata completions, which means the signaling
thread is unreliable even if we could represent it in condition
variables. As a result, the current system is wholly unsuited
for eliminating these priority inversions.
An AtomicWaitQueue is an object containing a lock. The queue
is eagerly allocated, and the lock is held, whenever a thread
is doing work that other threads might wish to block on. In
the metadata completion system, this means whenever we construct
a metadata cache entry and the metadata isn't already allocated
and transitively complete after said construction. Blocking
is done by safely acquiring a shared reference to the queue
object (which, in the current implementation, requires briefly
taking a lock that's global to the surrounding metadata cache)
and then acquiring the contained lock. For typical lock
implementations, this avoids priority inversions by temporarily
propagating the priority of waiting threads to the locking
threads.
Dependencies are unblocked by simply releasing the lock held
in the queue. The unblocking thread doesn't know exactly what
metadata are blocked on it and doesn't make any effort to
directly advance their completion; instead, the blocking
thread will wake up and then attempt to advance the dependent
metadata completion itself, eliminating a source of priority
overhang that affected the old system. Successive rounds of
unblocking (e.g. when a metadata makes partial progress but
isn't yet complete) can be achieved by creating a new queue
and unlocking the old one. We can still record dependencies
and use them to dynamically diagnose metadata cycles.
The new system allocates more eagerly than the old one.
Formerly, metadata completions which were never blocked never
needed to allocate a MetadataCompletionQueueEntry; we were
then unable to actually deallocate those entries once they
were allocated. The new system will allocate a queue for
most metadata completions, although, on the positive side,
we can reliably deallocate these queues. Cache entries are
also now slightly smaller because some of the excess storage
for status has been folded into the queue.
The fast path of an actual read of the metadata remains a
simple load-acquire. Slow paths may require a bit more
locking. On Darwin, the metadata cache lock can now use
os_unfair_lock instead of pthread_mutex_t (which is a massive
improvement) because it does not need to support associated
condition variables.
The excess locking could be eliminated with some sort of
generational scheme. Sadly, those are not portable, and I
didn't want to take it on up-front.
rdar://76127798
These fail with -requirement-machine-protocol-signatures=verify because
the GSB produces incorrect output. Enable the requirement machine
unconditionally for these tests, bypassing verification.
A new file test/Generics/same_type_requirements_in_protocol.swift
contains reduced versions of all of the failures, with FileCheck
used to confirm the exact requirement signature output.
The effect of passing -enable-copy-propagation is both to enable the
CopyPropagation pass to shorten object lifetimes and also to enable
lexical lifetimes to ensure that object lifetimes aren't shortened while
a variable is still in scope and used.
Add a new flag, -enable-lexical-borrow-scopes=true to override
-enable-copy-propagation's effect (setting it to ::ExperimentalLate) on
SILOptions::LexicalLifetimes that sets it to ::Early even in the face of
-enable-copy-propagation. The old flag -disable-lexical-lifetimes is
renamed to -enable-lexical-borrow-scopes=false but continues to set that
option to ::Off even when -enable-copy-propagation is passed.
