Skip to content

Fix typos in VISION and PROCESS documents. #2479

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jun 11, 2024
Merged

Fix typos in VISION and PROCESS documents. #2479

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion process.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Expand Down
4 changes: 2 additions & 2 deletions visions/embedded-swift.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Expand Down Expand Up @@ -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.
Expand Down
4 changes: 2 additions & 2 deletions visions/swift-testing.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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)).
Expand Down Expand Up @@ -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))
Expand Down