Merge branch 'main' into wip-ktoso-changelog

Author: DougGregor

CHANGELOG.md

@@ -5,6 +5,22 @@
 
 ## Swift 6.0
 
+* Swift 6 comes with a new language mode that prevents the risk of data races
+  at compile time. This guarantee is accomplished through _data isolation_; the
+  compiler will validate that data passed over a boundary between concurrently
+  executing code is either safe to reference concurrently, or mutually
+  exclusive access to the value is enforced.
+
+  The data-race safety checks were previously available in Swift 5.10 through
+  the `-strict-concurrency=complete` compiler flag. Complete concurrency
+  checking in Swift 5.10 was overly restrictive, and Swift 6 removes many
+  false-positive data-race warnings through better `Sendable` inference,
+  new analysis that proves mutually exclusive access when passing values with
+  non-`Sendable` type over isolation boundaries, and more.
+
+  You can enable the Swift 6 language mode using the `-swift-version 6`
+  compiler flag.
+
 * [SE-0428][]:
   Distributed actors now have the ability to support complete split server / 
   client systems, thanks to the new `@Resolvable` macro and runtime changes.
@@ -50,7 +66,7 @@ And the module structure to support such applications looks like this:
 ```
 
 * [SE-0424][]:
-  Serial executor gain a new customization point `checkIsolation()`, which can be
+  Serial executor gains a new customization point `checkIsolation()`, which can be
   implemented by custom executor implementations in order to provide a last resort  
   check before the isolation asserting APIs such as `Actor.assumeIsolated` or
   `assertIsolated` fail and crash.
@@ -59,6 +75,34 @@ And the module structure to support such applications looks like this:
   checking, and now even an actor which is "on a queue which is targeting 
   another specific queue" can be properly detected using these APIs.
 
+* [SE-0431][]:
+  You can now require a function value to carry its actor isolation
+  dynamically in a way that can be directly read by clients:
+
+  ```swift
+  func apply<R>(count: Int,
+                operation: @isolated(any) async () -> R) async -> [R]
+      where R: Sendable {
+    // implementation
+  }
+  ```
+
+  The isolation can read with the `.isolation` property, which has type
+  `(any Actor)?`:
+
+  ```swift
+  let iso = operation.isolation
+  ```
+
+  This capability has been adopted by the task-creation APIs in the
+  standard library.  As a result, creating a task with an actor-isolated
+  function will now synchronously enqueue the task on the actor, which
+  can be used for transitive event-ordering guarantees if the actor
+  guarantees that jobs will be run in the order they are enqueued, as
+  `@MainActor` does.  If the function is not explicitly isolated, Swift
+  still retains the right to optimize enqueues for functions that actually
+  start by doing work with different isolation from their formal isolation.
+
 * [SE-0423][]:
   You can now use `@preconcurrency` attribute to replace static actor isolation
   checking with dynamic checks for witnesses of synchronous nonisolated protocol
@@ -99,6 +143,21 @@ And the module structure to support such applications looks like this:
   The dynamic actor isolation checks can be disabled using the flag
   `-disable-dynamic-actor-isolation`.
 
+* [SE-0420][]:
+  `async` functions can now explicitly inherit the isolation of their caller
+  by declaring an `isolated` parameter with the default value of `#isolation`:
+
+  ```swift
+  func poll(isolation: isolated (any Actor)? = #isolation) async -> [Item] {
+    // implementation
+  }
+  ```
+
+  When the caller is actor-isolated, this allows it to pass isolated state
+  to the function, which would otherwise have concurrency problems.  The
+  function may also be able to eliminate unwanted scheduling changes, such
+  as when it can quickly return in a fast path without needing to suspend.
+
 * [SE-0418][]:
 
   The compiler would now automatically employ `Sendable` on functions
@@ -10496,19 +10555,23 @@ using the `.dynamicType` member to retrieve the type of an expression should mig
 [SE-0407]: https://github.com/apple/swift-evolution/blob/main/proposals/0407-member-macro-conformances.md
 [SE-0408]: https://github.com/apple/swift-evolution/blob/main/proposals/0408-pack-iteration.md
 [SE-0411]: https://github.com/apple/swift-evolution/blob/main/proposals/0411-isolated-default-values.md
-[SE-0417]: https://github.com/apple/swift-evolution/blob/main/proposals/0417-task-executor-preference.md
 [SE-0412]: https://github.com/apple/swift-evolution/blob/main/proposals/0412-strict-concurrency-for-global-variables.md
 [SE-0413]: https://github.com/apple/swift-evolution/blob/main/proposals/0413-typed-throws.md
+[SE-0414]: https://github.com/apple/swift-evolution/blob/main/proposals/0414-region-based-isolation.md
+[SE-0417]: https://github.com/apple/swift-evolution/blob/main/proposals/0417-task-executor-preference.md
+[SE-0418]: https://github.com/apple/swift-evolution/blob/main/proposals/0418-inferring-sendable-for-methods.md
+[SE-0420]: https://github.com/apple/swift-evolution/blob/main/proposals/0420-inheritance-of-actor-isolation.md
 [SE-0422]: https://github.com/apple/swift-evolution/blob/main/proposals/0422-caller-side-default-argument-macro-expression.md
+[SE-0423]: https://github.com/apple/swift-evolution/blob/main/proposals/0423-dynamic-actor-isolation.md
 [SE-0427]: https://github.com/apple/swift-evolution/blob/main/proposals/0427-noncopyable-generics.md
 [SE-0429]: https://github.com/apple/swift-evolution/blob/main/proposals/0429-partial-consumption.md
 [SE-0432]: https://github.com/apple/swift-evolution/blob/main/proposals/0432-noncopyable-switch.md
-[SE-0414]: https://github.com/apple/swift-evolution/blob/main/proposals/0414-region-based-isolation.md
 [SE-0430]: https://github.com/apple/swift-evolution/blob/main/proposals/0430-transferring-parameters-and-results.md
 [SE-0418]: https://github.com/apple/swift-evolution/blob/main/proposals/0418-inferring-sendable-for-methods.md
 [SE-0423]: https://github.com/apple/swift-evolution/blob/main/proposals/0423-dynamic-actor-isolation.md
 [SE-0424]: https://github.com/apple/swift-evolution/blob/main/proposals/0424-custom-isolation-checking-for-serialexecutor.md
 [SE-0428]: https://github.com/apple/swift-evolution/blob/main/proposals/0428-resolve-distributed-actor-protocols.md
+[SE-0431]: https://github.com/apple/swift-evolution/blob/main/proposals/0431-isolated-any-functions.md
 [#64927]: <https://github.com/apple/swift/issues/64927>
 [#42697]: <https://github.com/apple/swift/issues/42697>
 [#42728]: <https://github.com/apple/swift/issues/42728>

SwiftCompilerSources/Sources/Optimizer/PassManager/Context.swift

@@ -433,6 +433,34 @@ extension Type {
 //                          Builder initialization
 //===----------------------------------------------------------------------===//
 
+private extension Instruction {
+  /// Returns self, unless self is a meta instruction, in which case the next
+  /// non-meta instruction is returned. Returns nil if there are no non-meta
+  /// instructions in the basic block.
+  var nextNonMetaInstruction: Instruction? {
+    for inst in InstructionList(first: self) where !(inst is MetaInstruction) {
+      return inst
+    }
+    return nil
+  }
+
+  /// Returns the next interesting location. As it is impossible to set a
+  /// breakpoint on a meta instruction, those are skipped.
+  /// However, we don't want to take a location with different inlining
+  /// information than this instruction, so in that case, we will return the
+  /// location of the meta instruction. If the meta instruction is the only
+  /// instruction in the basic block, we also take its location.
+  var locationOfNextNonMetaInstruction: Location {
+    let location = self.location
+    guard !location.isInlined,
+          let nextLocation = nextNonMetaInstruction?.location,
+          !nextLocation.isInlined else {
+      return location
+    }
+    return nextLocation
+  }
+}
+
 extension Builder {
   /// Creates a builder which inserts _before_ `insPnt`, using a custom `location`.
   init(before insPnt: Instruction, location: Location, _ context: some MutatingContext) {
@@ -441,8 +469,23 @@ extension Builder {
               context.notifyInstructionChanged, context._bridged.asNotificationHandler())
   }
 
-  /// Creates a builder which inserts _before_ `insPnt`, using the location of `insPnt`.
+  /// Creates a builder which inserts before `insPnt`, using `insPnt`'s next
+  /// non-meta instruction's location.
+  /// This function should be used when moving code to an unknown insert point,
+  /// when we want to inherit the location of the closest non-meta instruction.
+  /// For replacing an existing meta instruction with another, use
+  /// ``Builder.init(replacing:_:)``.
   init(before insPnt: Instruction, _ context: some MutatingContext) {
+    context.verifyIsTransforming(function: insPnt.parentFunction)
+    self.init(insertAt: .before(insPnt),
+              location: insPnt.locationOfNextNonMetaInstruction,
+              context.notifyInstructionChanged, context._bridged.asNotificationHandler())
+  }
+
+  /// Creates a builder which inserts _before_ `insPnt`, using the exact location of `insPnt`,
+  /// for the purpose of replacing that meta instruction with an equivalent instruction.
+  /// This function does not delete `insPnt`.
+  init(replacing insPnt: MetaInstruction, _ context: some MutatingContext) {
     context.verifyIsTransforming(function: insPnt.parentFunction)
     self.init(insertAt: .before(insPnt), location: insPnt.location,
               context.notifyInstructionChanged, context._bridged.asNotificationHandler())
@@ -460,10 +503,10 @@ extension Builder {
     }
   }
 
-  /// Creates a builder which inserts _after_ `insPnt`, using the location of `insPnt`.
+  /// Creates a builder which inserts _after_ `insPnt`, using `insPnt`'s next
+  /// non-meta instruction's location.
   init(after insPnt: Instruction, _ context: some MutatingContext) {
-    context.verifyIsTransforming(function: insPnt.parentFunction)
-    self.init(after: insPnt, location: insPnt.location, context)
+    self.init(after: insPnt, location: insPnt.locationOfNextNonMetaInstruction, context)
   }
 
   /// Creates a builder which inserts at the end of `block`, using a custom `location`.
@@ -482,11 +525,12 @@ extension Builder {
   }
 
   /// Creates a builder which inserts at the begin of `block`, using the location of the first
-  /// instruction of `block`.
+  /// non-meta instruction of `block`.
   init(atBeginOf block: BasicBlock, _ context: some MutatingContext) {
     context.verifyIsTransforming(function: block.parentFunction)
     let firstInst = block.instructions.first!
-    self.init(insertAt: .before(firstInst), location: firstInst.location,
+    self.init(insertAt: .before(firstInst),
+              location: firstInst.locationOfNextNonMetaInstruction,
               context.notifyInstructionChanged, context._bridged.asNotificationHandler())
   }
 

SwiftCompilerSources/Sources/SIL/Instruction.swift

@@ -418,7 +418,16 @@ public protocol DebugVariableInstruction : VarDeclInstruction {
   var debugVariable: DebugVariable { get }
 }
 
-final public class DebugValueInst : Instruction, UnaryInstruction, DebugVariableInstruction {
+/// A meta instruction is an instruction whose location is not interesting as
+/// it is impossible to set a breakpoint on it.
+/// That could be because the instruction does not generate code (such as
+/// `debug_value`), or because the generated code would be in the prologue
+/// (`alloc_stack`).
+/// When we are moving code onto an unknown instruction (such as the start of a
+/// basic block), we want to ignore any meta instruction that might be there.
+public protocol MetaInstruction: Instruction {}
+
+final public class DebugValueInst : Instruction, UnaryInstruction, DebugVariableInstruction, MetaInstruction {
   public var varDecl: VarDecl? {
     VarDecl(bridged: bridged.DebugValue_getDecl())
   }
@@ -1127,7 +1136,7 @@ final public class InitBlockStorageHeaderInst: SingleValueInstruction {}
 
 public protocol Allocation : SingleValueInstruction { }
 
-final public class AllocStackInst : SingleValueInstruction, Allocation, DebugVariableInstruction {
+final public class AllocStackInst : SingleValueInstruction, Allocation, DebugVariableInstruction, MetaInstruction {
   public var hasDynamicLifetime: Bool { bridged.AllocStackInst_hasDynamicLifetime() }
 
   public var varDecl: VarDecl? {

SwiftCompilerSources/Sources/SIL/Location.swift

@@ -30,6 +30,7 @@ public struct Location: Equatable, CustomStringConvertible {
 
   public var hasValidLineNumber: Bool { bridged.hasValidLineNumber() }
   public var isAutoGenerated: Bool { bridged.isAutoGenerated() }
+  public var isInlined: Bool { bridged.isInlined() }
 
   public var isDebugSteppable: Bool { hasValidLineNumber && !isAutoGenerated }
 

cmake/modules/DarwinSDKs.cmake

@@ -1,15 +1,5 @@
-option(SWIFT_ENABLE_IOS32
-       "Build 32-bit variants of iOS"
-       TRUE)
-
-if(SWIFT_ENABLE_IOS32)
-set(SUPPORTED_IOS_ARCHS "arm64;arm64e")
-set(SUPPORTED_IOS_SIMULATOR_ARCHS "x86_64;arm64")
-else()
 set(SUPPORTED_IOS_ARCHS "arm64;arm64e")
 set(SUPPORTED_IOS_SIMULATOR_ARCHS "x86_64;arm64")
-endif()
-
 set(SUPPORTED_TVOS_ARCHS "arm64")
 set(SUPPORTED_TVOS_SIMULATOR_ARCHS "x86_64;arm64")
 set(SUPPORTED_WATCHOS_ARCHS "armv7k;arm64_32")

docs/ReferenceGuides/UnderscoredAttributes.md

@@ -955,12 +955,16 @@ the memory of the annotated type:
   threads, writes don't overlap with reads or writes coming from the same
   thread, and that the pointer is not used after the value is moved or
   consumed.
-- When the value is moved, a bitwise copy of its memory is performed to the new
-  address of the value in its new owner. As currently implemented, raw storage
-  types are not suitable for storing values which are not bitwise-movable, such
-  as nontrivial C++ types, Objective-C weak references, and data structures
-  such as `pthread_mutex_t` which are implemented in C as always requiring a
-  fixed address.
+- By default, when the value is moved a bitwise copy of its memory is performed
+  to the new address of the value in its new owner. This makes it unsuitable to
+  store not bitwise-movable types such as nontrivial C++ types, Objective-C weak
+  references, and data structures such as `pthread_mutex_t` which are
+  implemented in C as always requiring a fixed address. However, you can provide
+  `movesAsLike` to the `like:` version of this attribute to enforce that moving
+  the value will defer its move semantics to the type it's like. This makes it
+  suitable for storing such values that are not bitwise-movable. Note that the
+  raw storage for this variant must always be properly initialized after
+  initialization because foreign moves will assume an initialized state.
 
 Using the `@_rawLayout` attribute will suppress the annotated type from
 being implicitly `Sendable`. If the type is safe to access across threads, it
@@ -987,6 +991,11 @@ forms are currently accepted:
 - `@_rawLayout(likeArrayOf: T, count: N)` specifies the type's size should be
   `MemoryLayout<T>.stride * N` and alignment should match `T`'s, like an
   array of N contiguous elements of `T` in memory.
+- `@_rawLayout(like: T, movesAsLike)` specifies the type's size and alignment
+  should be equal to the type `T`'s. It also guarantees that moving a value of
+  this raw layout type will have the same move semantics as the type it's like.
+  This is important for things like ObjC weak references and non-trivial move
+  constructors in C++.
 
 A notable difference between `@_rawLayout(like: T)` and
 `@_rawLayout(likeArrayOf: T, count: 1)` is that the latter will pad out the