Expand alignedStorageForEmptyVaLists to eight Doubles. This produces more predictable output for code that calls a variadic function without parameters where the function still expects them, such as passing an arbitary string to a string formatting function. It's still unsound, but this makes it more predictable.
rdar://145083971
We introduce a new macro called #SwiftSettings that can be used in conjunction
with a new stdlib type called SwiftSetting to control the default isolation at
the file level. It overrides the current default isolation whether it is the
current nonisolated state or main actor (when -enable-experimental-feature
UnspecifiedMeansMainActorIsolated is set).
We don't have a great way to ensure that the current-global-actor hook
will get installed by the concurrency library with WebAssembly, so
temporarily work around the issue by relying on the fact that we also
aren't doing actual concurrency with WebAssembly.
Replace the pair of global actor type/conformance we are passing around with
a general "conformance execution context" that could grow new functionality
over time. Add three external symbols to the runtime:
* swift_conformsToProtocolWithExecutionContext: a conforms-to-protocol check
that also captures the execution context that should be checked before
using the conformance for anything. The only execution context right now
is for an isolated conformance.
* swift_isInConformanceExecutionContext: checks whether the function is
being executed in the given execution context, i.e., running on the
executor for the given global actor.
* swift_ConformanceExecutionContextSize: the size of the conformance
execution context. Client code outside of the Swift runtime can allocate
a pointer-aligned region of memory of this size to use with the runtime
functions above.
In the prior implementation of runtime resolution of isolated conformances,
the runtime had to look in both the protocol conformance descriptor and
in all conditional conformance requirements (recursively) to find any
isolated conformances. If it found one, it had to demangle the global
actor type to metadata. Since swift_conformsToProtocol is a hot path through
the runtime, we can't afford this non-constant-time work in the common
case.
Instead, cache the resolved global actor and witness table as part of the
conformance cache, so that we have access to this information every time
we look up a witness table for a conformance. Propagate this up through
various callers (e.g., generic requirement checking) to the point where
we either stash it in the cache or check it at runtime. This gets us down
to a very quick check (basically, NULL-or-not) for nonisolated conformances,
and just one check for isolated conformances.
Following the approach taken with the concurrency-specific type
descriptors, register a hook function for the "is current global actor"
check used for isolated conformances.
When establishing whether a given conformance is isolated, look through
the witness tables used to satisfy conditional requirements as well. This
is because an otherwise-nonisolated conditional conformance can become
isolated if one of its associated conformance requirements is satisfied
by an isolated conformance.
While here, make sure this code works with variadic generics, too.
Extend the metadata representation of protocol conformance descriptors
to include information about the global actor to which the conformance is
isolated (when there is one), as well as the conformance of that type to
the GlobalActor protocol. Emit this metadata whenever a conformance is
isolated.
When performing a conforms-to-protocol check at runtime, check whether
the conformance that was found is isolated. If so, extract the serial
executor for the global actor and check whether we are running on that
executor. If not, the conformance fails.
These should be available for any type of element `Span` can have in the future, including non-escapable elements. Making this change now avoids future churn.
Addresses rdar://146130842
PR 79186 (https://github.com/swiftlang/swift/pull/79186) moved one of
the mandatory passes from the C++ implementation to the Swift
implementation resulting in a compiler that is unable to build the
standard library. The pass used to ensure that inaccessible control-flow
positions after an infinite loop was marked with `unreachable` in SIL.
Since the pass is no longer running, any function that returns a value
that also has an infinite loop internally must place a fatalError after
the infinite loop or it will fail to compile as the compiler will
determine that the function does not return from all control flow paths
even though some of the paths are unreachable.
Adding `SWIFT_ENABLE_SWIFT_IN_SWIFT` option to enable or disable the
parts of Swift that require a Swift compiler to build. This is meant for
bootstrapping compilers on new platforms and is not guaranteed to result
in a compiler that will pass the test suite.
This option is on by default so that folks won't forget.
If the option is off, the resulting compiler does not include the Swift
optimizer sources in SwiftCompilerSources nor does the resulting
compiler have swift macro support.
- Write an overview of the type.
- Amend summaries of the initializers.
- Remove inapplicable example code.
- Add "Complexity: O(*n*)" to initializers.
- Add "Complexity: O(1)" to indexing APIs.
- Add FIXME comments.
