Feature/issue 72662 bad diagnostic for force unwrapped p

SwiftCompilerSources/Sources/SIL/Function.swift

@@ -147,7 +147,7 @@ final public class Function : CustomStringConvertible, HasShortDescription, Hash
     case .IsNotSerialized: return .notSerialized
     case .IsSerialized: return .serialized
     case .IsSerializedForPackage: return .serializedForPackage
-    default: fatalError()
+    @unknown default: fatalError()
     }
   }
 
@@ -156,7 +156,6 @@ final public class Function : CustomStringConvertible, HasShortDescription, Hash
     case .notSerialized: return .IsNotSerialized
     case .serialized: return .IsSerialized
     case .serializedForPackage: return .IsSerializedForPackage
-    default: fatalError()
     }
   }
 

benchmark/single-source/CharacterRecognizer.swift

@@ -13,7 +13,7 @@
 import TestsUtils
 
 public var benchmarks: [BenchmarkInfo] {
-  guard #available(macOS 9999, iOS 9999, watchOS 9999, tvOS 9999, *) else {
+  guard #available(macOS 14.0, iOS 17.0, watchOS 10.0, tvOS 17.0, *) else {
     return []
   }
   return [
@@ -82,7 +82,7 @@ let _asciiString = #"""
   """#
 let asciiString = String(repeating: _asciiString, count: 10)
 
-@available(macOS 9999, iOS 9999, watchOS 9999, tvOS 9999, *)
+@available(macOS 14.0, iOS 17.0, watchOS 10.0, tvOS 17.0, *)
 func run(string: String, n: Int) {
   var state = Unicode._CharacterRecognizer()
   var c = 0

benchmark/single-source/StringTests.swift

@@ -14,36 +14,43 @@ import TestsUtils
 @_spi(_Unicode)
 import Swift
 
-public let benchmarks = [
-  BenchmarkInfo(
-    name: "StringEqualPointerComparison",
-    runFunction: run_StringEqualPointerComparison,
-    tags: [.validation, .api, .String]),
-  BenchmarkInfo(
-    name: "StringHasPrefixAscii",
-    runFunction: run_StringHasPrefixAscii,
-    tags: [.validation, .api, .String],
-    legacyFactor: 10),
-  BenchmarkInfo(
-    name: "StringHasPrefixUnicode",
-    runFunction: run_StringHasPrefixUnicode,
-    tags: [.validation, .api, .String],
-    legacyFactor: 1000),
-  BenchmarkInfo(
-    name: "StringHasSuffixAscii",
-    runFunction: run_StringHasSuffixAscii,
-    tags: [.validation, .api, .String],
-    legacyFactor: 10),
-  BenchmarkInfo(
-    name: "StringHasSuffixUnicode",
-    runFunction: run_StringHasSuffixUnicode,
-    tags: [.validation, .api, .String],
-    legacyFactor: 1000),
-  BenchmarkInfo(
-    name: "StringIterateWords",
-    runFunction: run_iterateWords,
-    tags: [.validation, .String]),
-]
+public var benchmarks: [BenchmarkInfo] {
+  var result = [
+    BenchmarkInfo(
+      name: "StringEqualPointerComparison",
+      runFunction: run_StringEqualPointerComparison,
+      tags: [.validation, .api, .String]),
+    BenchmarkInfo(
+      name: "StringHasPrefixAscii",
+      runFunction: run_StringHasPrefixAscii,
+      tags: [.validation, .api, .String],
+      legacyFactor: 10),
+    BenchmarkInfo(
+      name: "StringHasPrefixUnicode",
+      runFunction: run_StringHasPrefixUnicode,
+      tags: [.validation, .api, .String],
+      legacyFactor: 1000),
+    BenchmarkInfo(
+      name: "StringHasSuffixAscii",
+      runFunction: run_StringHasSuffixAscii,
+      tags: [.validation, .api, .String],
+      legacyFactor: 10),
+    BenchmarkInfo(
+      name: "StringHasSuffixUnicode",
+      runFunction: run_StringHasSuffixUnicode,
+      tags: [.validation, .api, .String],
+      legacyFactor: 1000),
+  ]
+
+  if #available(macOS 15.0, iOS 18.0, watchOS 11.0, tvOS 18.0, visionOS 2.0, *) {
+    result.append(
+      BenchmarkInfo(
+        name: "StringIterateWords",
+        runFunction: run_iterateWords,
+        tags: [.validation, .String]))
+  }
+  return result
+}
 
 // FIXME(string)
 public func run_StringHasPrefixAscii(_ n: Int) {
@@ -1644,11 +1651,8 @@ architecture on Linux.</p>
 
 extension String {
   @inline(never)
-  @available(SwiftStdlib 5.9, *)
+  @available(macOS 15.0, iOS 18.0, watchOS 11.0, tvOS 18.0, visionOS 2.0, *)
   var _words: [Substring] {
-    guard #available(macOS 9999, iOS 9999, watchOS 9999, tvOS 9999, *) else {
-      fatalError("Can't run this benchmark")
-    }
     var result: [Substring] = []
 
     var i = startIndex
@@ -1666,6 +1670,7 @@ extension String {
   }
 }
 
+@available(macOS 15.0, iOS 18.0, watchOS 11.0, tvOS 18.0, visionOS 2.0, *)
 public func run_iterateWords(_ n: Int) {
   for _ in 0 ..< n {
     blackHole(swiftOrgHTML._words)

docs/DebuggingTheCompiler.md

@@ -36,6 +36,7 @@ benefit of all Swift developers.
         - [Bisecting on SIL optimizer pass counts to identify optimizer bugs](#bisecting-on-sil-optimizer-pass-counts-to-identify-optimizer-bugs)
         - [Using git-bisect in the presence of branch forwarding/feature branches](#using-git-bisect-in-the-presence-of-branch-forwardingfeature-branches)
         - [Reducing SIL test cases using bug_reducer](#reducing-sil-test-cases-using-bug_reducer)
+    - [Disabling PCH Verification](#disabling-pch-verification)
 - [Debugging the Compiler Build](#debugging-the-compiler-build)
     - [Build Dry Run](#build-dry-run)
 - [Debugging the Compiler Driver](#debugging-the-compiler-driver-build)
@@ -832,6 +833,19 @@ each time you change shas. To do this you can pass `--match-timestamp`
 to automatically checkout match the timestamp of the `apple/swift` repo
 across the other repos.
 
+## Disabling PCH Verification
+
+Sometimes one needs to try to compile against PCH modules where the PCH version
+verification checking is too strict. To work around this, one can disable the
+checking by passing in to swift:
+
+```sh
+-Xcc -Xclang -Xcc -fno-validate-pch
+```
+
+NOTE: If there are actual differences in between the on disk PCH format and the
+format expected by the compiler crashes and undefined behavior may result.
+
 # Debugging the Compiler Build
 
 ## Build Dry Run

docs/EmbeddedSwift/ABI.md

@@ -0,0 +1,37 @@
+# Embedded Swift -- ABI
+
+**⚠️ Embedded Swift is experimental. This document might be out of date with latest development.**
+
+**‼️ Use the latest downloadable 'Trunk Development' snapshot from swift.org to use Embedded Swift. Public releases of Swift do not yet support Embedded Swift.**
+
+For an introduction and motivation into Embedded Swift, please see "[A Vision for Embedded Swift](https://github.com/apple/swift-evolution/blob/main/visions/embedded-swift.md)", a Swift Evolution document highlighting the main goals and approaches.
+
+## ABI stability
+
+The ABI of code generated by Embedded Swift is not currently stable. For a concrete compiler version, it will be consistent, but do not mix code built with different compiler versions.
+
+Similarly, do not mix Embedded Swift code with full Swift code, as the ABIs are different. Details are described in the following sections.
+
+## Calling convention of Embedded Swift
+
+As of today, Embedded Swift has identical calling convention to full Swift. However, this does not need to continue in the future, and there should not be expectations that the ABI of Embedded Swift is compatible with full Swift.
+
+The compiler respects the ABIs and calling conventions of C and C++ when interoperating with code in those languages. Calling C/C++ functions from Embedded Swift code is supported, and similarly exporting Swift code via `@_extern`, `@_cdecl` or `@_expose` will match the right calling conventions that C/C++ expects.
+
+## Metadata ABI of Embedded Swift
+
+Embedded Swift eliminates almost all metadata compared to full Swift. However, class metadata is still used, because those serve as vtables for dynamic dispatch of methods to implement runtime polymorphism. The layout of Embedded Swift's class metadata is *different* from full Swift:
+
+- The **super pointer** pointing to the class metadata record for the superclass is stored at **offset 0**. If the class is a root class, it is null.
+- The **destructor pointer** is stored at **offset 1**. This function is invoked by Swift's deallocator when the class instance is destroyed.
+- The **ivar destroyer** is stored at **offset 2**. This function is invoked to destroy instance members when creation of the object is cancelled (e.g. in a failable initializer).
+- Lastly, the **vtable** is stored at **offset 3**: For each Swift class in the class's inheritance hierarchy, in order starting
+  from the root class and working down to the most derived class, the function pointers to the implementation of every method of the class in declaration order in stored.
+
+## Heap object layout in Embedded Swift
+
+Heap objects have the following layout in Embedded Swift:
+
+- The **isa pointer** (pointer to the class metadata) is stored at **offset 0**.
+- The **refcount** is stored inline at **offset 1**.
+- Normal stored properties follow.

docs/EmbeddedSwift/EmbeddedSwiftStatus.md

@@ -34,7 +34,7 @@ This status table describes which of the following standard library features can
 | Codable, Encodable, Decodable                              | No     |
 | Collection + related protocols                             | Yes    |
 | Collection algorithms (sort, reverse)                      | Yes    |
-| CustomStringConvertible, CustomDebugStringConvertible      | No     |
+| CustomStringConvertible, CustomDebugStringConvertible      | Yes, except those that require reflection (e.g. Array's .description)     |
 | Dictionary (dynamic heap-allocated container)              | Yes    |
 | FixedWidthInteger + related protocols                      | Yes    |
 | Hashable, Equatable, Comparable protocols                  | Yes    |
@@ -45,15 +45,15 @@ This status table describes which of the following standard library features can
 | Mirror (runtime reflection)                                | No, intentionally unsupported long-term |
 | Objective-C bridging                                       | No, intentionally unsupported long-term |
 | Optional                                                   | Yes    |
-| print / debugPrint                                         | Partial (only StaticStrings and integers) |
+| print / debugPrint                                         | Partial (only String, string interpolation, StaticStrings, integers, pointers and booleans) |
 | Range, ClosedRange, Stride                                 | Yes    |
 | Result                                                     | Yes    |
 | Set (dynamic heap-allocated container)                     | Yes    |                                      
 | SIMD types                                                 | Yes    |
 | StaticString                                               | Yes    |
-| String (dynamic)                                           | No (work in progress) |
-| String Interpolations                                      | No (work in progress) |
-| Unicode                                                    | No     |
+| String (dynamic)                                           | Yes    |
+| String Interpolations                                      | Yes    |
+| Unicode                                                    | Yes    |
 | Unsafe\[Mutable\]\[Raw\]\[Buffer\]Pointer                  | Yes    |
 | VarArgs                                                    | No     |
 

docs/EmbeddedSwift/UserManual.md

@@ -20,13 +20,13 @@ The following document explains how to use Embedded Swift's support in the Swift
 A typical setup and build + run cycle for an embedded development board involves:
 
 - (1) Getting an SDK with the C compilers, headers and libraries for the target
-- (2) Building the C source code, and Swift source code
+- (2) Building the C source code, and Swift source code into object files.
 - (3) Linking all the libraries, C object files, and Swift object files.
-- (4) Post-processing the linked firmware into a flashable format (UD2, BIN, or bespoke formats)
+- (4) Post-processing the linked firmware into a flashable format (UF2, BIN, or bespoke formats)
 - (5) Uploading the flashable binary to the board over a USB cable using some vendor-provided JTAG/SWD tool or by copying it to a fake USB Mass Storage volume presented by the board.
 - (6) Restarting the board, observing physical effects of the firmware (LEDs light up) or UART output over USB, or presence on network, etc.
 
-Most of these steps are out of scope for this document, instead refer to the vendor provided documentation and get familiar with the details of firmware development for your board without Swift in the mix first. Even if you want to build a completely pure Swift firmware, you are still very likely going to need the vendor provided tooling for linking, post-processing, uploading, etc.
+Most of these steps are out of scope for this document, instead refer to the vendor provided documentation. This document only focuses on (2) from the list above, and it's important that you first get familiar with the details of firmware development for your board without Swift in the mix. Even if you want to build a completely pure Swift firmware, you are still going to need the vendor provided tooling for linking, post-processing, uploading, etc.
 
 ## Building code using Embedded Swift
 
@@ -41,15 +41,15 @@ $ swiftc -target <target triple> -enable-experimental-feature Embedded -wmo \
 
 ### Building Swift firmware for an embedded target
 
-To build Swift firmware (for now ingnoring integration with SDKs, libraries and other pre-existing C code), we can use the `-target` argument to specify the CPU architecture. The target triple also decides whether the output object file will be an ELF file, or a Mach-O. For example:
+To build Swift firmware (for now ignoring integration with SDKs, libraries and other pre-existing C code), we can use the `-target` argument to specify the CPU architecture. The target triple also decides whether the output object file will be an ELF file, or a Mach-O. For example:
 
 ```bash
 # To build an ARMv7 Mach-O object file:
 $ swiftc -target armv7-apple-none-macho -enable-experimental-feature Embedded -wmo \
   input1.swift input2.swift ... -c -o output.o
 
 # To build an ARMv7 ELF object file:
-$ swiftc -target armv7-unknown-none-eabi -enable-experimental-feature Embedded -wmo \
+$ swiftc -target armv7-none-none-eabi -enable-experimental-feature Embedded -wmo \
   input1.swift input2.swift ... -c -o output.o
 ```
 
@@ -59,7 +59,7 @@ For example, a Raspberry Pi Pico / Pico W should target the ARMv6-M architecture
 
 ```bash
 # To build an ELF object file for ARMv6-M with soft float ABI (floating-point arguments passed in integer registers) and "short enums":
-$ swiftc -target armv6m-unknown-none-eabi -enable-experimental-feature Embedded -wmo \
+$ swiftc -target armv6m-none-none-eabi -enable-experimental-feature Embedded -wmo \
    -Xcc -mfloat-abi=soft -Xcc -fshort-enums \
   input1.swift input2.swift ... -c -o output.o
 ```
@@ -98,6 +98,58 @@ Segment __TEXT: 16384
 ...
 ```
 
+## Strings
+
+Both StaticString and String types are available in Embedded Swift. As is the case in desktop Swift, certain operations on strings require Unicode data tables for strict Unicode compliance. In Embedded Swift. these data tables are provided as a separate static library (libUnicodeDataTables.a) that users need to link in manually – if they need to use these string operations. If the library is required, linking will fail due to missing on one or more of the following symbols:
+
+```
+_swift_stdlib_getAge
+_swift_stdlib_getBinaryProperties
+_swift_stdlib_getCaseMapping
+_swift_stdlib_getComposition
+_swift_stdlib_getDecompositionEntry
+_swift_stdlib_getGeneralCategory
+_swift_stdlib_getGraphemeBreakProperty
+_swift_stdlib_getMapping
+_swift_stdlib_getMphIdx
+_swift_stdlib_getNameAlias
+_swift_stdlib_getNormData
+_swift_stdlib_getNumericType
+_swift_stdlib_getNumericValue
+_swift_stdlib_getScalarBitArrayIdx
+_swift_stdlib_getScalarName
+_swift_stdlib_getScript
+_swift_stdlib_getScriptExtensions
+_swift_stdlib_getSpecialMapping
+_swift_stdlib_getWordBreakProperty
+_swift_stdlib_isLinkingConsonant
+_swift_stdlib_nfd_decompositions
+```
+
+To resolve this, link in the libswiftUnicodeDataTables.a that's in Swift toolchain's resource directory (`lib/swift/`) under the target triple that you're using:
+
+```bash
+$ swiftc <inputs> -target armv6m-none-none-eabi -enable-experimental-feature Embedded -wmo -c -o output.o
+$ ld ... -o binary output.o $(dirname `which swiftc`)/../lib/swift/embedded/armv6m-none-none-eabi/libswiftUnicodeDataTables.a
+```
+
+**Unicode data tables are required for (list not exhaustive):**
+
+- Comparing String objects for equality
+- Sorting Strings
+- Using String's hash values, and in particular using String as dictionary keys
+- Using String's .count property
+- Using Unicode-aware string processing APIs (.split(), iterating characters, indexing)
+- Using Unicode-aware conversion String APIs (.uppercased(), .lowercased(), etc.)
+
+**For contrast, unicode data tables are *not required for* (list not exhaustive):**
+
+- Using StaticString
+- Creating, concatenating, string interpolating, and printing String objects
+- Using .utf8, .utf16, and .unicodeScalars views of strings, including their .count property, using them as dictionary keys
+
+Manually linking libUnicodeDataTables.a is required for several reasons, including acknowledging that the data tables are desirable: Since they have a non-negligible size, it's useful to be aware that you are using them.
+
 ## Conditionalizing compilation for Embedded Swift
 
 It's often useful to have source code be compilable under both regular Swift and Embedded Swift. The following syntax is available for that (but note that as the rest of Embedded Swift, it's experimental, subject to change and not considered source stable):
@@ -133,8 +185,7 @@ Features that are not available:
 - **Not available**: Runtime reflection (`Mirror` APIs).
 - **Not available**: Values of protocol types ("existentials"), e.g. `let a: Hashable = ...`, are not allowed. `Any` and `AnyObject` are also not allowed.
 - **Not available**: Metatypes, e.g. `let t = SomeClass.Type` or `type(of: value)` are not allowed.
-- **Not available yet (under development)**: The print() function for types other than StaticString and integers.
-- **Not available yet (under development)**: String. (StaticString **is** available).
+- **Not available**: Printing and stringification of arbitrary types (achieved via reflection in desktop Swift).
 - **Not available yet (under development)**: Swift Concurrency.
 
 For a more complete list of supported features in Embedded Swift, see [Embedded Swift -- Status](EmbeddedSwiftStatus.md).
@@ -159,7 +210,14 @@ The Embedded Swift standard library is distributed in the toolchain the same way
 
 ## Allocating and non-allocating Embedded Swift mode
 
-Embedded Swift does allow instantiating and using reference types (classes) which are refcounted objects allocated on the heap. A common case of needing those is for dynamic containers like arrays and sets (they use dynamically-sized heap-allocated class instances as their storage). Outside of creating class instances and explicitly calling allocation APIs (e.g. `UnsafeMutablePointer.allocate()`), Embedded Swift does not perform allocations or cause heap usage.
+Embedded Swift does allow instantiating and using reference types (classes) which are refcounted objects allocated on the heap. A common case of needing those is for dynamic containers like arrays and sets (they use dynamically-sized heap-allocated class instances as their storage). There is only a handful of Swift language features that cause allocations:
+
+- creating class instances,
+- escaping a closure that captures local variables,
+- creating an indirect enum case with a payload referencing the enum itself
+- explicitly calling allocation APIs (e.g. `UnsafeMutablePointer.allocate()`).
+
+Outside of those cases, Embedded Swift does not perform allocations or cause heap usage.
 
 Some embedded platforms don't have and/or don't want *any heap allocations whatsoever* and don't provide a heap at all. The `-no-allocations` compiler flag can be used to match that, which will cause the compiler to produce an error at compile time when creating class instances or calling allocation APIs.
 

docs/HowToGuides/GettingStarted.md

@@ -262,7 +262,7 @@ Build the toolchain with optimizations, debuginfo, and assertions, using Ninja:
 - macOS:
   ```sh
   utils/build-script --skip-build-benchmarks \
-    --skip-ios --skip-watchos --skip-tvos --swift-darwin-supported-archs "$(uname -m)" \
+    --skip-ios --skip-watchos --skip-tvos --skip-xros --swift-darwin-supported-archs "$(uname -m)" \
     --sccache --release-debuginfo --swift-disable-dead-stripping \
     --bootstrapping=hosttools
   ```