@mmerterden/multi-agent-pipeline 20.6.0 → 20.8.0

package/pipeline/skills/shared/external/swift-language/evals/evals.json

@@ -3,44 +3,41 @@
   "evals": [
     {
       "id": 0,
-      "name": "modern-language-refactor",
-      "prompt": "Review and modernize this Swift helper without changing behavior. Use current Swift language idioms where they help, but keep the answer concise.\n\n```swift\nenum Priority { case low, normal, high }\nenum ValidationError: Error { case empty, tooLong }\n\nfunc validateTitle(_ title: String) throws -> String {\n    if title.isEmpty {\n        throw ValidationError.empty\n    }\n    if title.count > 80 {\n        throw ValidationError.tooLong\n    }\n    return title.trimmingCharacters(in: .whitespacesAndNewlines)\n}\n\nfunc iconName(priority: Priority) -> String {\n    var name = \"circle\"\n    switch priority {\n    case .low:\n        name = \"arrow.down.circle\"\n    case .normal:\n        name = \"circle\"\n    case .high:\n        name = \"exclamationmark.circle\"\n    }\n    return name\n}\n\nfunc summarize(_ tags: [String]) -> String {\n    var urgentCount = 0\n    for tag in tags {\n        if tag == \"urgent\" { urgentCount += 1 }\n    }\n    return \"urgent: \\(urgentCount)\"\n}\n```",
-      "expected_output": "A concise modernization that uses guard preconditions, typed throws for the single validation error domain, switch expressions for conditional return, collection APIs such as count(where:), and explains why each change is appropriate.",
+      "prompt": "Modernise this Swift: a validateBooking(_:) function that throws a generic Error, nests three if-let blocks, fills a mutable var label through a switch statement before returning it, and counts invalid seats with seats.filter { !$0.isValid }.count. Keep it plain Swift.",
+      "expected_output": "A refactor that uses a typed throw for the single validation error type, guard-based preconditions, a switch expression and count(where:), with no detour into SwiftUI, concurrency or lint setup.",
       "files": [],
-      "assertions": [
-        "Uses `throws(ValidationError)` or explicitly recommends typed throws for the single validation error domain.",
-        "Uses `guard` for validation preconditions in `validateTitle(_:)`.",
-        "Rewrites `iconName(priority:)` with a `switch` expression or equivalent single-expression return without a mutable temporary variable.",
-        "Uses `count(where:)` rather than a manual loop for counting urgent tags.",
-        "Keeps the answer focused on Swift language idioms and does not expand into SwiftUI, concurrency, or lint configuration."
+      "expectations": [
+        "Declares the function with throws(ValidationError) or an equivalently named single error type and shows exhaustive catch handling",
+        "Replaces the nested if-let blocks with guard preconditions that exit early",
+        "Assigns the label directly from a switch expression instead of a mutable temporary",
+        "Uses count(where:) instead of filter followed by count",
+        "Does not add SwiftUI views, actors or tasks, or SwiftLint configuration"
       ]
     },
     {
       "id": 1,
-      "name": "swift63-interop-attributes",
-      "prompt": "Correct this Swift 6.3 interoperability/performance note for a team wiki. The draft says: `@c func export(_ bytes: UnsafeBufferPointer<UInt8>) -> Int32` is valid C export syntax, `@specialize` is the official function-specialization attribute, `@inline(always)` is just a hint, and module selectors are written `ModuleName.symbol`.\n\nGive a corrected note with minimal Swift examples.",
-      "expected_output": "A source-grounded correction that uses a C-compatible @c signature, names @specialized as the official explicit-specialization attribute, treats @inline(always) as a guaranteed inlining request that can fail when impossible, and uses ModuleName::symbol module selectors.",
+      "prompt": "Check these Swift 6.3 changes: we export @c func hashBytes(_ data: UnsafeBufferPointer<UInt8>) -> UInt64 for our C library, annotate a generic sum with @specialize(where T == Int), expect @inline(always) to be only a hint, and resolve a clash between two Logger types with a typealias file.",
+      "expected_output": "Corrections for each attribute: a C-compatible @c signature, the official @specialized spelling, the guaranteed-inlining semantics of @inline(always), and module selectors for the name clash.",
       "files": [],
-      "assertions": [
-        "Rejects `UnsafeBufferPointer<UInt8>` in an `@c` exported function signature because it is a Swift struct, not a C-representable parameter.",
-        "Shows an `@c` example using C-compatible pointer and scalar types, optionally with a custom C symbol name.",
-        "Uses `@specialized`, not `@specialize`, for explicit specialization.",
-        "States that Swift 6.3 `@inline(always)` guarantees inlining for direct calls and can produce an error when inlining is impossible.",
-        "Uses `ModuleName::symbol` syntax for module selectors."
+      "expectations": [
+        "Rejects UnsafeBufferPointer<UInt8> in a @c signature because it is a Swift struct that C cannot represent, and lists the other Swift-only types that are rejected",
+        "Shows a corrected @c function that takes a C-compatible pointer plus a scalar count, optionally with a custom symbol name via @c(Name)",
+        "Uses @specialized rather than @specialize or @_specialize",
+        "States that @inline(always) guarantees inlining at direct call sites and produces a compile error when inlining is impossible",
+        "Resolves the clash with ModuleName::Logger module selectors instead of aliasing"
       ]
     },
     {
       "id": 2,
-      "name": "sibling-boundary-routing",
-      "prompt": "I have three cleanup requests in an iOS package: build full Codable API models with snake_case key strategies and date decoding, design locale-sensitive currency/date/list formatting for several markets, and decide whether a reusable Swift helper should use `some`, `any`, or `Never`. Which parts should the Swift language skill own, and which should be routed to sibling skills? Include only minimal examples.",
-      "expected_output": "A boundary-aware routing answer that keeps swift-language focused on core type-system features such as some/any/Never, routes deep Codable/API decoding to swift-codable, routes detailed formatting and localization-sensitive display work to swift-formatstyle or ios-localization, and avoids implementing the sibling domains.",
+      "prompt": "For our loyalty module: should the points publisher and a validation helper use Result<Int, Never> and throws(Never)? Also please build the Codable models with snake_case keys and a date strategy, and localize the points balance for each market.",
+      "expected_output": "An answer that owns the some/any/Never language questions in full and routes Codable model design and formatting or localization to the sibling skills without implementing them.",
       "files": [],
-      "assertions": [
-        "Says swift-language owns the core type-system/language decision around `some`, `any`, and `Never`.",
-        "Correctly explains that `Never` is uninhabited/bottom-type-like in expression contexts but does not implicitly conform to arbitrary protocols.",
-        "Routes full Codable API model design, key strategies, and date decoding to `swift-codable`.",
-        "Routes detailed FormatStyle and locale-sensitive display work to `swift-formatstyle` and mentions localization review when appropriate.",
-        "Does not provide a full Codable model suite or full formatting/localization implementation."
+      "expectations": [
+        "Explains Never as uninhabited, bottom-like in expressions, and without implicit conformance to arbitrary protocols",
+        "Explains what Result<Int, Never> and throws(Never) mean for callers",
+        "Routes Codable models, key strategies and date decoding to swift-codable",
+        "Routes number formatting and market display to swift-formatstyle together with a localization review",
+        "Does not write full Codable models or formatting implementations for the sibling areas"
       ]
     }
   ]

package/pipeline/skills/shared/external/swift-language/references/swift-attributes-interop.md

@@ -1,97 +1,120 @@
-# Swift Attributes and C Interoperability
+# Swift 6.3 attributes for interop, performance and layout
 
-Attributes and interoperability features for Swift. Covers C-calling-convention export, module disambiguation, performance annotations, and symbol visibility control.
+Attributes that became official in Swift 6.3. Each section names the Swift
+Evolution proposal so the exact rules can be checked there.
 
-## Contents
+## @c
 
-- [C Interoperability  -  `@c` Attribute](#c-interoperability--c-attribute)
-- [Module Selectors](#module-selectors)
-- [Performance Annotations](#performance-annotations)
-- [Symbol Visibility and Layout](#symbol-visibility-and-layout)
-
-## C Interoperability  -  `@c` Attribute
-
-The `@c` attribute (SE-0495) marks a Swift function for direct C-calling-convention export. The function becomes callable from C, C++, and Objective-C without bridging headers or `@_cdecl`.
+SE-0495 adds `@c`. It exports a Swift function using the C calling convention,
+so C, C++ and Objective-C code can call it directly: no bridging header and no
+underscored `@_cdecl`.
 
 ```swift
-@c(MyLib_processBuffer)
-public func processBuffer(_ buffer: UnsafePointer<UInt8>?, _ count: Int32) -> Int32 {
-    guard let buffer else { return 0 }
-    return buffer.pointee == 0 ? 0 : count
+@c
+func checksum8(_ bytes: UnsafePointer<UInt8>?, _ length: Int32) -> UInt8 {
+    guard let bytes, length > 0 else { return 0 }
+    var total: UInt8 = 0
+    for i in 0..<Int(length) { total &+= bytes[i] }
+    return total
+}
+
+@c(codec_reset_state)
+func resetState(_ flags: UInt32) -> Int32 {
+    flags == 0 ? 0 : -1
 }
 ```
 
-**Requirements:**
-- Parameters and return types must be C-compatible (primitives, pointers, tuples of C-compatible types)
-- No Swift-only types (`String`, `Array`, `UnsafeBufferPointer`, closures, generic placeholders, etc.) in the signature
-- The function must be a module-level free function (not a method)
-- Use `@c(CustomName)` when the C symbol should differ from the Swift function name
+`@c(codec_reset_state)` sets the exported C symbol when it should differ from
+the Swift name.
 
-## Module Selectors
+Signature rules:
 
-SE-0491 adds `ModuleName::symbolName` syntax to disambiguate identically named symbols from different modules without `import` aliasing.
+- Parameters and return values must be representable in C: integer and
+  floating-point primitives, `Bool`, raw pointers and `UnsafePointer` /
+  `UnsafeMutablePointer` to C-compatible pointees, `OpaquePointer`, and tuples
+  built from C-compatible types.
+- Swift-only types are rejected. When correcting a signature, list them:
+  `String`, `Array`, `UnsafeBufferPointer` (a Swift struct, not a C type),
+  closures, and generic placeholders. Replace a buffer with a base pointer plus
+  a count.
+- The function must be a free function at module scope, not a method on a
+  type.
 
-```swift
-import NetworkingA
-import NetworkingB
+## Module selectors
 
-// Both modules export a top-level `configure()` function
-func setup() {
-    NetworkingA::configure()
-    NetworkingB::configure()
-}
+SE-0491 introduces `ModuleName::symbolName`. When two imported modules export
+the same name, the selector picks one without import aliasing or a wrapper
+typealias. It works for types and functions alike.
 
-// Works with types too
-let client: NetworkingA::Client = .init()
+```swift
+import HTTPKit
+import MockHTTP
+
+let live = HTTPKit::Session()
+let fake = MockHTTP::Session()
+let body = HTTPKit::encodeQuery(["q": "swift"])
 ```
 
-## Performance Annotations
+## Performance annotations
 
-### `@specialized`
+### @specialized
 
-SE-0460 makes `@specialized` an official attribute (previously underscored as `@_specialize`). Forces the compiler to emit a specialized version of a generic function for specific concrete types.
+SE-0460 makes `@specialized` official; the older spelling was `@_specialize`.
+It tells the compiler to emit specialised copies of a generic function for the
+listed concrete types, so callers with those types skip generic dispatch.
+Stack one attribute per type:
 
 ```swift
-@specialized(where T == Int)
-@specialized(where T == Double)
-func sum<T: Numeric>(_ values: [T]) -> T {
+@specialized(where Element == Int)
+@specialized(where Element == Float)
+func total<Element: AdditiveArithmetic>(_ values: [Element]) -> Element {
     values.reduce(.zero, +)
 }
 ```
 
-### `@inline(always)` Guarantee
+Spell it `@specialized`; `@specialize` does not exist.
+
+### @inline(always)
 
-SE-0496 guarantees `@inline(always)` will inline the function at every call site. Previously it was a hint the compiler could ignore. A compilation error is now emitted if inlining is impossible (e.g., recursive calls).
+SE-0496 turns `@inline(always)` from a hint into a guarantee: the body is
+inlined at every direct call site. If inlining cannot happen, for example in a
+recursive function, the compiler reports an error instead of silently
+ignoring the request.
 
 ```swift
 @inline(always)
-func fastPath(_ x: Int) -> Int {
-    x &+ 1  // Guaranteed to be inlined at every call site
-}
+func squared(_ x: Double) -> Double { x * x }
 ```
 
-## Symbol Visibility and Layout
+## Symbol visibility and layout
 
-### `@export`
+### @export
 
-SE-0497 gives explicit control over symbol visibility and definition availability:
+SE-0497 defines `@export` with two modes that replace the underscored
+attributes:
 
-- `@export(interface)`  -  ensures a callable symbol exists in the binary but hides the definition from clients (no inlining/specialization by external callers). Replaces `@_neverEmitIntoClient`.
-- `@export(implementation)`  -  makes the definition available for inlining/specialization but does not guarantee a callable symbol. Replaces `@_alwaysEmitIntoClient`.
+| Spelling | Effect | Replaces |
+|---|---|---|
+| `@export(interface)` | a callable symbol is emitted in the binary; the body stays hidden from clients, so they cannot inline or specialise it | `@_neverEmitIntoClient` |
+| `@export(implementation)` | the body is available to clients for inlining and specialisation; no callable symbol is guaranteed | `@_alwaysEmitIntoClient` |
 
 ```swift
 @export(interface)
-public func stableAPI() -> Int {
-    // Callable symbol guaranteed; definition hidden from clients
-    return computeValue()
-}
+public func licenseCheck(_ key: String) -> Bool { key.count == 16 }
+
+@export(implementation)
+public func clampedIndex(_ i: Int, count: Int) -> Int { max(0, min(i, count - 1)) }
 ```
 
-### `@section` and `@used`
+### @section and @used
 
-SE-0492 places global variables into named binary sections and prevents dead-stripping. Primarily for Embedded Swift and systems programming.
+SE-0492 adds `@section("name")`, which places a global in a named section of
+the binary, and `@used`, which keeps the linker from stripping a symbol that
+nothing references. They target Embedded Swift, firmware and other systems
+code.
 
 ```swift
-@section(".mydata") @used
-var configFlag: Int32 = 1
+@section("__DATA,__fwinfo")
+@used
+let firmwareRevision: UInt32 = 0x0203
 ```