chore(deps): update dependency swiftlang/swift to v6.3.2

[renovate]

This PR contains the following updates:

Package	Update	Change
swiftlang/swift	minor	6.0 → 6.3.2

---

Release Notes

swiftlang/swift (swiftlang/swift)

v6.3.2

Compare Source

v6.3.1: Swift 6.3.1 Release

Compare Source

• Install via Swiftly swiftly install 6.3.1
• WinGet Support will be available soon (PR)
• Docker images will be available on hub.docker.com/_/swift soon. (PR)
• Forums post: https://forums.swift.org/t/announcing-swift-6-3-1/86080

v6.3

Compare Source

• [SE-0489][]:
  When you encounter errors while encoding or decoding Codable types, the resulting error messages are now more human-readable thanks to improved debugDescription output.

  Before:

  typeMismatch(Swift.String, Swift.DecodingError.Context(codingPath: [_CodingKey(stringValue: "Index 0", intValue: 0), CodingKeys(stringValue: "address", intValue: nil), CodingKeys(stringValue: "city", intValue: nil), CodingKeys(stringValue: "birds", intValue: nil), _CodingKey(stringValue: "Index 1", intValue: 1), CodingKeys(stringValue: "name", intValue: nil)], debugDescription: "Expected to decode String but found number instead.", underlyingError: nil))

  After:

  DecodingError.typeMismatch: expected value of type String. Path: [0].address.city.birds[1].name. Debug description: Expected to decode String but found number instead.

• [SE-0491][]:
  You can now use a module selector to specify which module Swift should look inside to find a named declaration. A
  module selector is written before the name it qualifies and consists of the module name and two colons (::):

  // This type conforms to the `View` protocol from `SwiftUI`, even if other
  // modules have also declared a type named `View`:
  struct MyView: SwiftUI::View { ... }

  A module selector can also be applied to the name of a member; this is helpful if extensions in other modules have
  added an ambiguous overload:

  // Calls the `data(using:)` method added by `Foundation`, even if other
  // modules have added identical overloads of `data(using:)`.
  let data = "a little bit of text".Foundation::data(using: .utf8)

  When a module selector is used, Swift skips past any enclosing scopes and starts its search at the top level of the
  module; this means that certain declarations, such as local variables and generic parameter types, cannot be found
  with a module selector. Constraints in where clauses also cannot use a module selector to refer to an associated
  type.

  Module selectors are primarily intended to be used when working around unavoidable conflicts, such as when two
  modules you don't control both use the same name. API designs which force clients to use a module selector are not
  recommended; it is usually better to rename a declaration instead. (1948104)

• If you maintain a module built with Library Evolution, you can now configure Swift to use module selectors to improve
  the robustness of its module interface file. This is especially helpful if your module declares a type with the same
  name as the module itself. To opt in to this behavior, add the -enable-module-selectors-in-module-interface flag to
  the OTHER_SWIFT_FLAGS build setting.

• Concurrency-related APIs like Task and string-processing-related APIs like Regex can now be qualified by the name
  Swift, just like other standard library APIs:

  Swift.Task { ... }
  func match(_ regex: Swift.Regex<(Substring)>) { ... }

  The old _Concurrency and _StringProcessing names are still supported for backwards compatibility, and Embedded
  Swift projects must still explicitly import _Concurrency to access concurrency APIs.

v6.2.4: Swift 6.2.4 Release

Compare Source

v6.2.3: Swift 6.2.3 Release

Compare Source

v6.2.2: Swift 6.2.2 Release

Compare Source

v6.2.1: Swift 6.2.1 Release

Compare Source

v6.2

Compare Source

• [SE-0472][]:
  Introduced new Task.immediate and taskGroup.addImmediateTask APIs, which allow a task to run "immediately" in the
  calling context if its isolation is compatible with the enclosing one. This can be used to create tasks which execute
  without additional scheduling overhead, and allow for finer-grained control over where a task begins running.

  The canonical example for using this new API is using an unstructured immediate task like this:

  func synchronous() { // synchronous function
  // executor / thread: "T1"
  let task: Task<Void, Never> = Task.immediate {
  // executor / thread: "T1"
  guard keepRunning() else { return } // synchronous call (1)
  
      // executor / thread: "T1"
      await noSuspension() // potential suspension point #&#8203;1 // (2)
      
      // executor / thread: "T1"
      await suspend() // potential suspension point #&#8203;2 // (3), suspend, (5)
      // executor / thread: "other"
  }
  
  // (4) continue execution
  // executor / thread: "T1"
  }

• [SE-0371][]:
  Actor and global actor annotated types may now declare a synchronous isolated deinit, which allows such deinitializer
  to access actor isolated state while deinitializing the actor. This enables actor deinitializers to safely access
  and shut down or close resources during an actors deinitialization, without explicitly resorting to unstructured
  concurrency tasks.

  class NonSendableAhmed { 
    var state: Int = 0
  }
  
  @​MainActor
  class Maria {
    let friend: NonSendableAhmed
  
    init() {
      self.friend = NonSendableAhmed()
    }
  
    init(sharingFriendOf otherMaria: Maria) {
      // While the friend is non-Sendable, this initializer and
      // and the otherMaria are isolated to the MainActor. That is,
      // they share the same executor. So, it's OK for the non-Sendable value
      // to cross between otherMaria and self.
      self.friend = otherMaria.friend
    }
    
    isolated deinit {
      // Used to be a potential data race. Now, deinit is also
      // isolated on the MainActor, so this code is perfectly
      // correct.
      friend.state += 1
    }
  }
    
  func example() async {
    let m1 = await Maria()
    let m2 = await Maria(sharingFriendOf: m1)
    doSomething(m1, m2)
  }

• [SE-0469][]:
  Swift concurrency tasks (both unstructured and structured, via the TaskGroup addTask APIs) may now be given
  human-readable names, which can be used to support debugging and identifying tasks.

  let getUsers = Task("Get Users for \(accountID)") {
    await users.get(accountID)
  }

• [SE-0462][]:
  Task priority escalation may now be explicitly caused to a Task, as well as reacted to using the new task priority escalation handlers:

  // priority: low
  // priority: high!
  await withTaskPriorityEscalationHandler {
  await work()
  } onPriorityEscalated: { oldPriority, newPriority in // may not be triggered if ->high escalation happened before handler was installed
  // do something
  }

• [SE-0461][]:
  Nonisolated asynchronous functions may now execute on the calling actor, when the upcoming feature NonisolatedNonsendingByDefault
  is enabled, or when explicitly opted-into using the nonisolated(nonsending) keywords. This allows for fine grained control
  over where nonisolated asynchronous functions execute, and allows for the default behavior of their execution to be changed
  from always executing on the global concurrent pool, to the calling actor, which can yield noticeable performance improvements
  thanks to less executor hopping when nonisolated and isolated code is invoked in sequence.

  This also allows for safely using asynchronous functions on non-sendable types from actors, like so:

  class NotSendable {
    func performSync() { ... }
  
    nonisolated(nonsending)
    func performAsync() async { ... }
  }
  
  actor MyActor {
    let x: NotSendable
  
    func call() async {
      x.performSync() // okay
  
      await x.performAsync() // okay
    }
  }

• The Swift compiler no longer diagnoses references to declarations that are
  potentially unavailable because the platform version might not be new enough
  when those references occur inside of contexts that are also unavailable to
  that platform. This addresses a long-standing nuisance for multi-platform
  code. However, there is also a chance that existing source code may become
  ambiguous as a result:

  struct A {}
  struct B {}
  
  func potentiallyAmbiguous(_: A) {}
  
  @​available(macOS 99, *)
  func potentiallyAmbiguous(_: B) {}
  
  @​available(macOS, unavailable)
  func unavailableOnMacOS() {
    potentiallyAmbiguous(.init()) // error: ambiguous use of 'init()'
  }

  Code that is now ambiguous as a result should likely be restructured since
  disambiguation based on platform introduction alone has never been a reliable
  strategy, given that the code would eventually become ambiguous anyways when
  the deployment target is raised.

• [SE-0470][]:
  A protocol conformance can be isolated to a specific global actor, meaning that the conformance can only be used by code running on that actor. Isolated conformances are expressed by specifying the global actor on the conformance itself:

  protocol P {
    func f()
  }
  
  @​MainActor
  class MyType: @​MainActor P {
    /*@​MainActor*/ func f() {
      // must be called on the main actor
    }
  }

  Swift will produce diagnostics if the conformance is directly accessed in code that isn't guaranteed to execute in the same global actor. For example:

  func acceptP<T: P>(_ value: T) { }
  
  /*nonisolated*/ func useIsolatedConformance(myType: MyType) {
    acceptP(myType) // error: main actor-isolated conformance of 'MyType' to 'P' cannot be used in nonisolated context
  }

  To address such issues, only use an isolated conformance from code that executes on the same global actor.

• [SE-0419][]:
  Introduced the new Runtime module, which contains a public API that can
  generate backtraces, presently supported on macOS and Linux. Capturing a
  backtrace is as simple as

  import Runtime
  
  func foo() {
    // Without symbols
    let backtrace = try! Backtrace.capture()
  
    print(backtrace)
  
    // With symbol lookup
    let symbolicated = backtrace.symbolicated()!
  
    print(symbolicated)
  }

• [SE-0458][]:
  Introduced an opt-in mode for strict checking of memory safety, which can be
  enabled with the compiler flag -strict-memory-safety. In this mode,
  the Swift compiler will produce warnings for uses of memory-unsafe constructs
  and APIs. For example,

  func evilMalloc(size: Int) -> Int {
    // use of global function 'malloc' involves unsafe type 'UnsafeMutableRawPointer'
    return Int(bitPattern: malloc(size))
  }

  These warnings are in their own diagnostic group (StrictMemorySafety) and can
  be suppressed by ackwnowledging the memory-unsafe behavior, for
  example with an unsafe expression:

  func evilMalloc(size: Int) -> Int {
    return unsafe Int(bitPattern: malloc(size)) // no warning
  }

v6.1.3: Swift 6.1.3 Release

Compare Source

v6.1.2: Swift 6.1.2 Release

Compare Source

v6.1.1

Compare Source

• Class methods and initializers that satisfy protocol requirements now properly
  invoke subclass overrides when called in generic contexts. For example:

  protocol P {
    class func foo()
  }
  
  class C: P {
    class func foo() { println("C!") }
  }
  
  class D: C {
    override class func foo() { println("D!") }
  }
  
  func foo<T: P>(x: T) {
    x.dynamicType.foo()
  }
  
  foo(C()) // Prints "C!"
  foo(D()) // Used to incorrectly print "C!", now prints "D!"

  (1882821)

v6.1

Compare Source

• [#​78389][]:
  Errors pertaining to the enforcement of [any syntax][SE-0335] on boxed
  protocol types (aka existential types), including those produced by enabling
  the upcoming feature ExistentialAny, are downgraded to warnings until a
  future language mode.

  These warnings can be escalated back to errors with -Werror ExistentialAny.

• Previous versions of Swift would incorrectly allow Objective-C -init...
  methods with custom Swift names to be imported as initializers, but with base
  names other than init. The compiler now diagnoses these attributes and
  infers a name for the initializer as though they are not present.

• Projected value initializers are now correctly injected into calls when
  an argument exactly matches a parameter with an external property wrapper.

  For example:

  struct Binding {
    ...
    init(projectedValue: Self) { ... }
  }
  
  func checkValue(@​Binding value: Int) {}
  
  func use(v: Binding<Int>) {
    checkValue($value: v)
    // Transformed into: `checkValue(value: Binding(projectedValue: v))`
  }

  Previous versions of the Swift compiler incorrectly omitted projected value
  initializer injection in the call to checkValue because the argument type
  matched the parameter type exactly.

• [SE-0444][]:
  When the upcoming feature MemberImportVisibility is enabled, Swift will
  require that a module be directly imported in a source file when resolving
  member declarations from that module:

  let recipe = "2 slices of bread, 1.5 tbs peanut butter".parse()
  // error: instance method 'parse()' is inaccessible due to missing import of
  //        defining module 'RecipeKit'
  // note:  add import of module 'RecipeKit'

  This new behavior prevents ambiguities from arising when a transitively
  imported module declares a member that conflicts with a member of a directly
  imported module.

• Syntactic SourceKit queries no longer attempt to provide information
  within the inactive #if regions. For example, given:

  #if DEBUG
  extension MyType: CustomDebugStringConvertible {
    var debugDescription: String { ... }
  }
  #endif

  If DEBUG is not set, SourceKit results will not involve the
  inactive code. Clients should use either SourceKit-LSP or
  swift-syntax for syntactic queries that are independent of the
  specific build configuration.

• [SE-0442][]:
  TaskGroups can now be created without explicitly specifying their child task's result types:

  Previously the child task type would have to be specified explicitly when creating the task group:

  await withTaskGroup(of: Int.self) { group in 
    group.addTask { 12 }
  
    return await group.next()
  } 

  Now the type is inferred based on the first use of the task group within the task group's body:

  await withTaskGroup { group in 
    group.addTask { 12 }
  
    return await group.next()
  } 

v6.0.3: Swift 6.0.3 Release

Compare Source

v6.0.2: Swift 6.0.2 Release

Compare Source

v6.0.1: Swift 6.0.1 Release

Compare Source

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.