averello/swift-mirror
1
0
Fork 0
mirror of https://github.com/apple/swift.git synced 2025-12-14 20:36:38 +01:00
Code Issues Packages Projects Releases Wiki Activity

[NFC] Fix a few typos (#58739)

Browse Source 
* typo: "an an" -> "an"

* typo: "used used" -> "used"

* typo: "template template" -> "template"

* typo: "is is" -> "it is"

* typo: "lastest" -> "latest"

* typo: "instantanious" -> "instantaneous"
This commit is contained in:
Joseph Kato
2022-05-08 06:27:54 -07:00
committed by GitHub
parent 361947275e
commit a1a5038863
4 changed files with 15 additions and 15 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
docs/AndroidBuild.md
View File

@@ -34,7 +34,7 @@ git clone https://github.com/apple/swift-corelibs-xctest swift-corelibs-xctest
git clone https://github.com/compnerd/swift-build swift-build
```
## 1. Acquire the lastest toolchain and dependencies
## 1. Acquire the latest toolchain and dependencies
1. Download the toolchain, ICU, libxml2, and curl for android from
[Azure](https://dev.azure.com/compnerd/swift-build) into `S:\b\a\Library`.

6
docs/CppInteroperability/CppInteroperabilityManifesto.md
View File

@@ -500,7 +500,7 @@ accepts an address.
C++ has complex overload resolution rules, in part to support certain API design
patterns. Some API design patterns appeared as a consequence of overload
resolution rules. Therefore, in C++ an "API atom" is an an overload set, not an
resolution rules. Therefore, in C++ an "API atom" is an overload set, not an
individual function ([CppCon 2018: Titus Winters "Modern C++ Design (part 1 of
2)"](https://www.youtube.com/watch?v=xTdeZ4MxbKo)). The same is also the case in
Swift, so, fundamentally, there is no impedance mismatch here.
@@ -938,7 +938,7 @@ be handled in Swift.
While it is possible to [propagate C++ exceptions](#exceptions) thrown by normal
member functions to Swift code, special member functions are different as they
used used to implement value witnesses, which are called by the compiler
used to implement value witnesses, which are called by the compiler
implicitly. Therefore, either such exceptions have to be mapped to fatal errors
(as we do for other unhandled C++ exceptions), or calls to such special member
functions must be prevented statically.
@@ -2337,7 +2337,7 @@ different APIs across specializations of the same class. All instantiations of a
generic type in Swift have the API described in the generic declaration (with
type parameters substituted), plus applicable conditional extensions.
C++ templates support non-type template parameters, template template
C++ templates support non-type template parameters, template
parameters, and parameter packs (variadic generics), all of which are not
supported in Swift.

18
docs/CppInteroperability/InteropOddities.md
View File

@@ -1,23 +1,23 @@
# C++ Interoperability Oddities
C++ APIs may have slightly different behavior than other C++ APIs. This is a general catch-all document where these
C++ APIs may have slightly different behavior than other C++ APIs. This is a general catch-all document where these
oddities are recorded along with a few other things that are good to know when using C++ interop.
**Parameters with reference types**
Parameters that have mutable reference types are bridged as inout. Parameters with immutable reference types (const ref)
are bridged as value types. ⚠️ This will change as soon as Swift has a way to represent immutable borrows. ⚠️
Parameters that have mutable reference types are bridged as inout. Parameters with immutable reference types (const ref)
are bridged as value types. ⚠️ This will change as soon as Swift has a way to represent immutable borrows. ⚠️
**Lifetimes**
Currently, lifetimes are extended to the end of the lexical scope if any unsafe pointers are used in that scope. TODO:
this should be updated to extend lifetimes whenever a C++ type is used in that scope. Currently, if there is no
unsafe pointer used in the scope, then normal Swift lifetime rules apply.
Currently, lifetimes are extended to the end of the lexical scope if any unsafe pointers are used in that scope. TODO:
this should be updated to extend lifetimes whenever a C++ type is used in that scope. Currently, if there is no
unsafe pointer used in the scope, then normal Swift lifetime rules apply.
**Borrowing Self**
For mutating methods, self is borrowed and the access to self lasts for the duration of the call. For non-mutating
methods, the access to self is currently instantanious. ⚠️ In the very near future we plan to borrow self in both cases.
For mutating methods, self is borrowed and the access to self lasts for the duration of the call. For non-mutating
methods, the access to self is currently instantaneous. ⚠️ In the very near future we plan to borrow self in both cases.
This will be a source breaking change from what native Swift methods do. ⚠️
_More to come soon :)_
_More to come soon :)_

4
docs/SILMemoryAccess.md
View File

@@ -293,7 +293,7 @@ scope:
end_access %access : $*S
```
Note that is is possible to have a nested access scope on the address
Note that it is possible to have a nested access scope on the address
of a struct field, which may show up as an access of
struct_element_addr after inlining. The rule is that access
projections cannot occur outside of the outermost access scope within
@@ -396,7 +396,7 @@ instructions may reference the same variable. To find all global uses,
the client must independently find all global variable references
within the function. Clients that need to know which SILValue base was
discovered during use-def traversal in all cases can make use of
`AccessStorageWithBase` or `AccessPathWithBase`.
`AccessStorageWithBase` or `AccessPathWithBase`.
### AccessPath