Skip to content

Commit 79fec2d

Browse files
committed
minor spelling tweaks
1 parent 0d4a585 commit 79fec2d

File tree

6 files changed

+11
-11
lines changed

6 files changed

+11
-11
lines changed

docs/ByteTree.md

+5-5
Original file line numberDiff line numberDiff line change
@@ -13,20 +13,20 @@ For example, the string "Hello World" would be encoded as `(uint32_t)11` `"Hello
1313

1414
## Serialization of objects
1515

16-
An object consists of its size, measured in the number of fields and represented as a `uint_32t` in little endian order, followed by the direct concatenation of its fields. Because each field is again prefixed with its size, no delimites are necessary in between the fields.
16+
An object consists of its size, measured in the number of fields and represented as a `uint_32t` in little endian order, followed by the direct concatenation of its fields. Because each field is again prefixed with its size, no delimits are necessary in between the fields.
1717

18-
To distinguish scalars and objects, the size of objects has its most-siginificant bit set to 1. It must be ignored to retrieve the number of fields in the object.
18+
To distinguish scalars and objects, the size of objects has its most-significant bit set to 1. It must be ignored to retrieve the number of fields in the object.
1919

2020
Arrays are modelled as objects whose fields are all of the same type and whose length is variadic (and is indicated by the object's size).
2121

2222
## Versioning
2323

24-
The ByteTree format is prepended by a 4-byte protocol version number that describes the version of the object tree that was serialized. Its exact semantics are up to each specific application, but it is encouraged to interpret it as a two-comentent number where the first component, consisting of the three most significant bytes, is incremented for breaking changes and the last byte is incremented for backwards-compatible changes.
24+
The ByteTree format is prepended by a 4-byte protocol version number that describes the version of the object tree that was serialized. Its exact semantics are up to each specific application, but it is encouraged to interpret it as a two-component number where the first component, consisting of the three most significant bytes, is incremented for breaking changes and the last byte is incremented for backwards-compatible changes.
2525

26-
## Forward compatilibity
26+
## Forward compatibility
2727

2828
Fields may be added to the end of objects in a backwards compatible manner (older deserialisers will still be able to deserialise the format). It does so by skipping over all fields that are not read during deserialisation. Newer versions of the deserialiser can detect if recently added fields are not present in the serialised data by inspecting the `numFields` property passed during deserialisation.
2929

3030
## Serialization safety
3131

32-
Since all fields in objects are accessed by their index, issues quickly arise if a new field is accidentally added at the beginning of an object. To prevent issues like this, the ByteTree serialiser and deserialiser requires the explicit specification of each field's index within the object. These indicies are never serialised. Their sole purpose is to check that all fields are read in the correct order in assertion builds.
32+
Since all fields in objects are accessed by their index, issues quickly arise if a new field is accidentally added at the beginning of an object. To prevent issues like this, the ByteTree serialiser and deserialiser requires the explicit specification of each field's index within the object. These indices are never serialised. Their sole purpose is to check that all fields are read in the correct order in assertion builds.

docs/CompilerPerformance.md

+2-2
Original file line numberDiff line numberDiff line change
@@ -695,7 +695,7 @@ files in `<directory>`.
695695
696696
This option also provides _some_ high-level counters that are "always available"
697697
regardless of whether you're using an assert or release build, though assert
698-
builds still get _more_ counters (all of those available thorugh
698+
builds still get _more_ counters (all of those available through
699699
`-print-stats`). If you are using a new-enough compiler, `-stats-output-dir`
700700
often simplifies analysis, since its output is machine-readable and aggregates
701701
all the jobs in a multi-job compilation, and there's a post-processing script
@@ -1322,7 +1322,7 @@ internals of the compiler, just time and patience.
13221322
13231323
- Add Open Source projects to the
13241324
[source-compatibility testsuite](https://swift.org/source-compatibility/).
1325-
Apple's internal CI infastructure is now tracking selected non-assert-build
1325+
Apple's internal CI infrastructure is now tracking selected non-assert-build
13261326
`UnifiedStatsReporter` counters on those projects, and the team is far
13271327
more likely to catch a regression if it's shown by a project in the testsuite.
13281328

docs/Random.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -13,4 +13,4 @@ following implementation details:
1313
- Linux, FreeBSD, and other UNIX-like platforms use `getrandom(2)` when available;
1414
otherwise, they read from `/dev/urandom`.
1515
- Fuchsia platforms use `getentropy(3)`.
16-
- Windows paltforms use `BCryptGenRandom`.
16+
- Windows platforms use `BCryptGenRandom`.

docs/SIL.rst

+1-1
Original file line numberDiff line numberDiff line change
@@ -4750,7 +4750,7 @@ A ``convert_escape_to_noescape [not_guaranteed] %opd`` indicates that the
47504750
lifetime of its operand was not guaranteed by SILGen and a mandatory pass must
47514751
be run to ensure the lifetime of ``%opd``` for the conversion's uses.
47524752

4753-
A ``convert_escape_to_noescape [escaped]`` indiciates that the result was
4753+
A ``convert_escape_to_noescape [escaped]`` indicates that the result was
47544754
passed to a function (materializeForSet) which escapes the closure in a way not
47554755
expressed by the convert's users. The mandatory pass must ensure the lifetime
47564756
in a conservative way.

docs/SILProgrammersManual.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -172,7 +172,7 @@ TBD: Possibly link to a separate document explaining the architecture of IRGen.
172172
## SILAnalysis and the PassManager
173173

174174
TBD: describe the mechanism by which passes invalidate and update the
175-
PassManager and its avaiable analyses.
175+
PassManager and its available analyses.
176176

177177
## High Level SIL Optimizations
178178

docs/Windows.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -19,7 +19,7 @@ Currently there are three supported ways to build Swift for Windows.
1919
`clang-cl` is recommended over MSVC for building Swift on Windows.
2020
Although it is possible to build the compiler and the standard library with
2121
MSVC to use those built products to compile a Swift program, it won't be
22-
possible to run the binary without seperately obtaining the Swift runtime. On
22+
possible to run the binary without separately obtaining the Swift runtime. On
2323
the other hand, `clang-cl` is able to build the runtime, which makes it
2424
possible to build and run all the components required for Swift natively on
2525
Windows.

0 commit comments

Comments
 (0)