Correct typos / spelling / grammar in multiple docs

Author: kubamracek

Sources/EmbeddedSwift/Documentation.docc/CompilerDetails/ABI.md

@@ -10,7 +10,7 @@ Similarly, do not mix Embedded Swift code with full Swift code, as the ABIs are
 
 ## Symbol mangling under Embedded Swift
 
-Since Swift 5.0, the stable ABI mangling schema uses the `$s` prefix on all Swift symbols. Because Embedded Swift's ABI differs from the stable ABI, and furthermore because it's not expected to be stable, Embedded Swift uses a `$e` mangling prefix. The logic and structure of the mangling stays the same, the only difference is the prefix.
+Since Swift 5.0, the stable ABI mangling scheme uses the `$s` prefix on all Swift symbols. Because Embedded Swift's ABI differs from the stable ABI, and furthermore because it's not expected to be stable, Embedded Swift uses a `$e` mangling prefix. The logic and structure of the mangling stays the same, the only difference is the prefix.
 
 ## Calling convention of Embedded Swift
 

Sources/EmbeddedSwift/Documentation.docc/GettingStarted/Introduction.md

@@ -10,7 +10,7 @@ Embedded Swift is an experimental and rapidly developing feature of the Swift la
 
 ## How does Embedded Swift differ from regular Swift?
 
-Regular Swift is not a good fit for small constrained environments like microcontrollers, mainly due to codesize and memory footprint. Regular Swift typically requires at least a few megabytes of code and data to support dynamic language features like reflection, and separately compiled generics with ABI stability. Embedded Swift on the other hand can be deployed to environments with as little as kilobytes of available memory. This is achieved by:
+Regular Swift is not a good fit for small constrained environments like microcontrollers, mainly due to codesize and memory footprint. Regular Swift typically requires at least a few megabytes of code and data to support dynamic language features like reflection, and separately compiled generics with ABI stability. Embedded Swift, on the other hand, can be deployed to environments with as little as kilobytes of available memory. This is achieved by:
 
 - Eliminating runtime type metadata where possible
 - Removing reflection capabilities

Sources/EmbeddedSwift/Documentation.docc/GettingStarted/LanguageSubset.md

@@ -2,9 +2,9 @@
 
 Details of the Embedded Swift language subset compared to full Swift
 
-Embedded Swift is a subset of the Swift language, and some features are not available in Embedded Swift. This is neccessary in order to achieve small binaries with effective dead-code elimination and minimized system dependencies.
+Embedded Swift is a subset of the Swift language, and some features are not available in Embedded Swift. This is necessary in order to achieve small binaries with effective dead-code elimination and minimized system dependencies.
 
-That said, *the vast majority* of the Swift language works exactly the same in Embedded Swift. This includes cenerics, protocols, enums with associated values, tuples, optionals, classes (instances are allocated on the heap and refcounted just like in regular Swift), inheritance, runtime polymorphism, arrays (heap-allocated copy-on-write just like in regular Swift) and much more.
+That said, *the vast majority* of the Swift language works exactly the same in Embedded Swift. This includes generics, protocols, enums with associated values, tuples, optionals, classes (instances are allocated on the heap and refcounted just like in regular Swift), inheritance, runtime polymorphism, arrays (heap-allocated copy-on-write just like in regular Swift) and much more.
 
 Note that there are no behavior changes in Embedded Swift compared to full Swift, and Embedded Swift is strictly a *subset* and not a *dialect*. Any code compatible with Embedded Swift will also compile and have the same semantics in full Swift.
 
@@ -15,8 +15,8 @@ Note that there are no behavior changes in Embedded Swift compared to full Swift
 - **Not available**: Throwing errors or `any Error` type (in contrast with "typed throws", which *is* supported in Embedded Swift).
 - **Not available**: Metatypes, e.g. `let t = SomeClass.Type` or `type(of: value)` are not allowed.
 - **Not available**: Printing and stringification of arbitrary types (which is achieved via reflection in desktop Swift).
-- **Not available**: Using non-fimal generic class methods. See <doc:NonFinalGenericMethods> for details on this.
-- **Not availble**: Weak and unowned references.
+- **Not available**: Using non-final generic class methods. See <doc:NonFinalGenericMethods> for details on this.
+- **Not available**: Weak and unowned references.
 
 ## Compilation facilities that are not available
 

Sources/EmbeddedSwift/Documentation.docc/GuidedExamples/PicoGuide.md

@@ -29,7 +29,7 @@ If you have the Wi-Fi enabled Pico W board instead of the regular Pico, note tha
 
 Install [CMake 3.29](https://cmake.org/) or newer.
 
-To test that you have all the neccessary parts installed, you can run the following commands in a terminal:
+To test that you have all the necessary parts installed, you can run the following commands in a terminal:
 
 ```shell
 $ swift --version

Sources/EmbeddedSwift/Documentation.docc/GuidedExamples/STM32BaremetalGuide.md

@@ -4,7 +4,7 @@ Program a STM32 microcontroller directly with low-level Swift code
 
 This tutorial will guide you through setting up a baremetal STM32 project with Embedded Swift to create a simple LED blinking application with text output to UART, the "Hello World" of embedded systems. Concretely, we'll be using the STM32F746G-DISCO (discovery) development board, but the setup will work (with only small tweaks) on most other STM32 devices.
 
-We will be writing a full firmware from scratch including low-level boot code, direct hardware register configuration, a custom linker script and more. Besides educational purposes, this level of control typically only needed in specialized setups because it involves more work and more complexity. If you want a simpler path to get started, you can integrate with an existing embedded SDK (like STCube or BSPs) instead, which will  offers higher-level APIs and hardware abstraction. Check out <doc:IntegratingWithPlatforms> for guidance on common integration patterns.
+We will be writing a full firmware from scratch including low-level boot code, direct hardware register configuration, a custom linker script and more. Besides educational purposes, this level of control is typically only needed in specialized setups because it involves more work and more complexity. If you want a simpler path to get started, you can integrate with an existing embedded SDK (like STCube or BSPs) instead, which offers higher-level APIs and hardware abstraction. Check out <doc:IntegratingWithPlatforms> for guidance on common integration patterns.
 
 ## Overall plan
 

Sources/EmbeddedSwift/Documentation.docc/SDKSupport/IntegrateWithPico.md

@@ -1,6 +1,6 @@
 # Raspberry Pi Pico SDK
 
-Setting up a project that can seamlessly use C API from the Pico SDK.
+Setting up a project that can seamlessly use C APIs from the Pico SDK.
 
 > Warning: Embedded Swift is experimental. Use the latest downloadable 'Trunk Development' snapshot from swift.org to use Embedded Swift. Public releases of Swift do not yet support Embedded Swift.
 

Sources/EmbeddedSwift/Documentation.docc/SDKSupport/IntegratingWithPlatforms.md

@@ -4,9 +4,9 @@ Understand the common patterns and approaches for integrating Swift with existin
 
 ## Overview
 
-Most embedded platforms provide SDKs consisting of drivers, libraries, and HAL (Hardware Abstraction Layer) components, typically written in C. Embedded Swift's C interoperability makes it possible to seamlessly integrate with these existing SDKs.
+Most embedded platforms provide SDKs consisting of drivers, libraries, and HAL (Hardware Abstraction Layer) components, typically written in the C language. Embedded Swift's C interoperability makes it possible to seamlessly integrate with these existing SDKs.
 
-This will enable using the entire API surface of an SDK directly from Swift, and it usually the easiest way to get started — because all functionality from the SDK will simply be available in your Swift code. Additionally, you could build Swift wrappers around the C SDK to provide a more idiomatic Swift API. This approach requires more a bit more work but can result in a more ergonomic and type-safe interface, leveraging Swift's strong type system and safety features to prevent common errors when interacting with low-level hardware.
+This will enable using the entire API surface of an SDK directly from Swift, and is usually the easiest way to get started — because all functionality from the SDK will simply be available in your Swift code. Additionally, you could build Swift wrappers around the C SDK to provide a more idiomatic Swift API. This approach requires a bit more work but can result in a more ergonomic and type-safe interface, leveraging Swift's strong type system and safety features to prevent common errors when interacting with low-level hardware.
 
 Alternatively, for the most constrained environments or when you need complete control over the hardware, you can develop baremetal Swift applications without relying on any SDK. This approach requires implementing your own hardware initialization code and peripheral drivers directly in Swift or in C with Swift wrappers. Baremetal development gives you the maximum flexibility but requires deeper understanding of the target hardware.
 

Sources/EmbeddedSwift/Documentation.docc/UsingEmbeddedSwift/Existentials.md

@@ -17,7 +17,7 @@ Existentials are restricted in Embedded Swift in multiple ways, for multiple rea
 Embedded Swift allows and supports class-bound existentials:
 
 ```swift
-procotol ClassBoundProtocol: AnyObject { // ✅, this means any type that wants to conform to ClassBoundProtocol must be a class type
+protocol ClassBoundProtocol: AnyObject { // ✅, this means any type that wants to conform to ClassBoundProtocol must be a class type
     func foo()
 }
 

Sources/EmbeddedSwift/Documentation.docc/UsingEmbeddedSwift/Libraries.md

@@ -4,10 +4,10 @@ Understand the library setup and linkage model of Embedded Swift
 
 Traditional library build and use model of Swift is that library code is compiled into a .swiftmodule, containing the interfaces, and a compiled library with binary code, either a .a static library or a .dylib/.so dynamic library. A client's build then uses the .swiftmodule at compile-time, and the static/dynamic library at link-time.
 
-The library model in Embedded Swift works slightly differently: All Swift source code of a library is promoted into being inlineable and visible to client builds (this is necessary for generic code, and beneficial for optimizations for non-generic code), and ends up serialized into the .swiftmodule, the interface of the library. Therefore, the compiled code of a library is never needed, and doesn't even need to be produced. For example:
+The library model in Embedded Swift works slightly differently: All Swift source code of a library is promoted into being inlinable and visible to client builds (this is necessary for generic code, and beneficial for optimizations for non-generic code), and ends up serialized into the .swiftmodule, the interface of the library. Therefore, the compiled code of a library is never needed, and doesn't even need to be produced. For example:
 
 ```bash
-# Build the library, only as a .swiftmomodule. Notice that we never build the .o or .a for the library.
+# Build the library, only as a .swiftmodule. Notice that we never build the .o or .a for the library.
 $ swiftc -target <target> -enable-experimental-feature Embedded -wmo \
   a.swift b.swift -module-name MyLibrary -emit-module -emit-module-path ./MyLibrary.swiftmodule