From 1b92e4c816e817ce1717c3d6ae6aa54c10fe5ce4 Mon Sep 17 00:00:00 2001 From: Alexander Cyon Date: Mon, 10 Jun 2024 23:51:31 +0200 Subject: [PATCH] Fix typos in VISION and PROCESS documents. --- process.md | 2 +- visions/embedded-swift.md | 4 ++-- visions/swift-testing.md | 4 ++-- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/process.md b/process.md index 10ddb7c687..72040190a4 100644 --- a/process.md +++ b/process.md @@ -95,7 +95,7 @@ Please state explicitly whether you believe that the proposal should be accepted 1. Expand the rough sketch into a formal proposal using the [proposal template](proposal-templates/0000-swift-template.md). 1. In the [swift-evolution repository][swift-evolution-repo], open a [draft pull request][draft-pr] that adds your proposal to the [proposals directory](/proposals). - 1. Anounce the pull request on the forums and edit the root post to link out to the pull request. + 1. Announce the pull request on the forums and edit the root post to link out to the pull request. 1. Refine the formal proposal in the open as you receive further feedback on the forums or the pull request. A ripe proposal is expected to address commentary from present and past discussions of the idea. diff --git a/visions/embedded-swift.md b/visions/embedded-swift.md index dcf77a059a..7bd8d7aa50 100644 --- a/visions/embedded-swift.md +++ b/visions/embedded-swift.md @@ -11,7 +11,7 @@ However, lots of embedded platforms and low-level environments have constraints * Popular MCU board families and manufacturers (Arduino, STM32, ESP32, NXP, etc.) commonly offer boards that only have an order of 10’s or 100’s of kB of memory available. * Firmware, and especially firmware projects that are run from SRAM, or ROM * (2) Environments where runtime dependencies, implicit runtime calls, and heap allocations are restricted - * Low-level environments without an underlaying operating system, such as bootloaders, hypervisors, firmware + * Low-level environments without an underlying operating system, such as bootloaders, hypervisors, firmware * Operating system kernels, kernel extensions, and other non-userspace software components * Userspace components that are too low-level in terms of dependencies, namely anything that the Swift runtime depends on. * A special case here is the Swift runtime itself, which is today written in C++. The concepts described further in this document allow Swift to become the implementation language instead. @@ -96,7 +96,7 @@ The following describes the high-level points in the approach to implement Embed * **Specialization is required on all uses of generics and protocols** at compile-time, and libraries are compiled in a way that allows cross-module specialization (into clients of the libraries). * Required specialization (also known as monomorphization in other compilers/languages) needs type parameters of generic types and functions to always be compile-time known at the caller site, and then the compiler creates a specialized instantiation of the generic type/function that is no longer generic. The result is that the compiled code does not need access to any type metadata at runtime. - * This compilation mode will not support separate compilation of generics, as that makes specialization not possible. Instead, library code providing generic types and functions will be required to provide function bodies as serialized SIL (effectively, “source code”) to clients via the mechanism descibed below. + * This compilation mode will not support separate compilation of generics, as that makes specialization not possible. Instead, library code providing generic types and functions will be required to provide function bodies as serialized SIL (effectively, “source code”) to clients via the mechanism described below. * **Library code is built as always inlinable and “emitIntoClient”** to support the specialization of generics/protocols in use sites that are outside of the library. * **This applies to the standard library, too**, and we shall distribute the standard library built this way with the toolchain. * This effectively provides the source code of libraries to application builds. diff --git a/visions/swift-testing.md b/visions/swift-testing.md index 812f2d2766..e08e1b7338 100644 --- a/visions/swift-testing.md +++ b/visions/swift-testing.md @@ -622,7 +622,7 @@ reduce the need for suspension points. #### Test discovery -To faciliate test discovery, the attached macros above will eventually use a +To facilitate test discovery, the attached macros above will eventually use a feature such as `@linkage`, an attribute for controlling low-level symbol linkage (see [pitch](https://forums.swift.org/t/pitch-2-low-level-linkage-control/69752)). @@ -962,7 +962,7 @@ qualification of many other components in the stack. The maintainers of this project will work with other Swift workgroups or steering groups to help enable support on new platforms. -One reason why broad plaform support is important is so that this project can +One reason why broad platform support is important is so that this project can eventually support testing the Swift standard library. The standard library currently uses a custom library for testing ([StdlibUnittest](https://github.com/apple/swift/tree/main/stdlib/private/StdlibUnittest))