Merge pull request #2481 from swiftwasm/main

[pull] swiftwasm from main

Author: pull[bot]

CHANGELOG.md

@@ -33,7 +33,7 @@ Note that these branches come not from the "development" branches (above), but t
 | ----------- | -----------------
 | next        | swift/next
 
-`swift/next` is a branch for LLVM that includes all changes necessary to support Swift. Changes from llvm.org's master branch are automatically merged in. Why isn't this just `swift/main`? Well, because LLVM changes *very* rapidly, and that wouldn't be very stable. However, we do want to make sure the Swift stuff keeps working.
+`swift/next` is a branch for LLVM that includes all changes necessary to support Swift. Changes from llvm.org's main branch are automatically merged in. Why isn't this just `swift/main`? Well, because LLVM changes *very* rapidly, and that wouldn't be very stable. However, we do want to make sure the Swift stuff keeps working.
 
 If you are making changes to LLVM to support Swift, you'll probably need to work on them in `swift/main` to test them against Swift itself, but they should be committed to `swift/next`, and cherry-picked to the current release branch (`swift/release/x.y`) if needed. Remember, the release branches are automerged into `swift/main` on a regular basis.
 
@@ -60,9 +60,9 @@ You can use any of the branch names as the argument to `--scheme`, such as `main
 
   1) LLVM Project changes that don't depend on Swift
 
-     - New commits go to `master` in the upstream [llvm-project](https://github.com/llvm/llvm-project).
+     - New commits go to `main` in the upstream [llvm-project](https://github.com/llvm/llvm-project).
 
-     - Then cherry-pick these commits to an appropriate, `swift/main` aligned `apple/stable/*` branch in Apple's fork of [llvm-project](https://github.com/apple/llvm-project). Please see [Apple's branching scheme](https://github.com/apple/llvm-project/blob/apple/master/apple-docs/AppleBranchingScheme.md) document to determine which `apple/stable/*` branch you should cherry-pick to.
+     - Then cherry-pick these commits to an appropriate, `swift/main` aligned `apple/stable/*` branch in Apple's fork of [llvm-project](https://github.com/apple/llvm-project). Please see [Apple's branching scheme](https://github.com/apple/llvm-project/blob/apple/main/apple-docs/AppleBranchingScheme.md) document to determine which `apple/stable/*` branch you should cherry-pick to.
 
      Note that **no new changes should be submitted directly to `apple/main`**. We are actively working on eliminating the differences from upstream LLVM.
 
@@ -84,5 +84,5 @@ Some branches are *automerged* into other branches, to keep them in sync. This i
 
 ### LLVM Project
 - `swift/release/x.y` (the *latest* release branch) is automerged into `swift/main`
-- llvm.org's `master` is automerged into `swift/next`
+- llvm.org's `main` is automerged into `swift/next`
 - llvm.org's release branch *may* be automerged into `swift/release/x.y`, if they are in sync

docs/Branches.md

@@ -274,7 +274,7 @@ func caller() {
 To understand the constraints that Swift puts on `inout` parameters, let's take
 a look at the mental model for introduced in the [Ownership
 manifesto](OwnershipManifesto.md) and in [SE-0176 Enforce Exclusive Access to
-Memory](https://github.com/apple/swift-evolution/blob/master/proposals/0176-enforce-exclusive-access-to-memory.md).
+Memory](https://github.com/apple/swift-evolution/blob/main/proposals/0176-enforce-exclusive-access-to-memory.md).
 When the caller binds a storage reference to an `inout` parameter, it starts a
 non-instantaneous access to the whole value that occupies the storage. This
 access ends when the callee returns.  Overlapping accesses are not allowed, and
@@ -1804,7 +1804,7 @@ dynamically, some are undefined behavior.
 
 The backdoors are disallowed by the exclusivity rule (from [SE-0176 Enforce
 Exclusive Access to
-Memory](https://github.com/apple/swift-evolution/blob/master/proposals/0176-enforce-exclusive-access-to-memory.md)):
+Memory](https://github.com/apple/swift-evolution/blob/main/proposals/0176-enforce-exclusive-access-to-memory.md)):
 
 > two accesses to the same variable are not allowed to overlap unless both
 > accesses are reads
@@ -2875,7 +2875,7 @@ struct MyCxxCollection {
 
 Swift has an equivalent for C++'s `operator()`: `callAsFunction` (introduced in
 [SE-0253: Callable values of user-defined nominal
-types](https://github.com/apple/swift-evolution/blob/master/proposals/0253-callable.md)).
+types](https://github.com/apple/swift-evolution/blob/main/proposals/0253-callable.md)).
 
 ```c++
 // C++ header.
@@ -2922,7 +2922,7 @@ non-throwing Swift functions. If a C++ function called from Swift throws an
 exception that is not caught within the C++ code, the program will terminate.
 
 This approach is similar to that taken by the [Python interop
-library](https://github.com/pvieito/PythonKit/blob/master/PythonKit/Python.swift),
+library](https://github.com/pvieito/PythonKit/blob/main/PythonKit/Python.swift),
 which also terminates the program by default if a Python exception is raised and
 not caught within the Python code.
 
@@ -3470,7 +3470,7 @@ A sidecar annotation file allows to add arbitrary attributes to declarations
 parsed from a header file. You can find examples of such files in the [apinotes
 directory](../apinotes). APINotes files
 are handled by the [APINotes library in
-Clang](https://github.com/apple/llvm-project/tree/apple/master/clang/lib/APINotes).
+Clang](https://github.com/apple/llvm-project/tree/apple/main/clang/lib/APINotes).
 Clang reads an APINotes file alongside the header file; Clang injects attributes
 specified by APINotes into the AST parsed from the header.
 

docs/CppInteroperabilityManifesto.md

@@ -607,19 +607,19 @@ missing important content from the downstream branch. As an example,
 consider a situation where one has the following straw man commit flow
 graph:
 
-    github/master -> github/tensorflow
+    github/main -> github/tensorflow
 
 In this case if one attempts to use `git-bisect` on
 github/tensorflow, `git-bisect` will sometimes choose commits from
-github/master resulting in one being unable to compile/test specific
+github/main resulting in one being unable to compile/test specific
 tensorflow code that has not been upstreamed yet. Even worse, what if
 we are trying to bisect in between two that were branched from
 github/tensorflow and have had subsequent commits cherry-picked on
 top. Without any loss of generality, lets call those two tags
 `tag-tensorflow-bad` and `tag-tensorflow-good`. Since both of
 these tags have had commits cherry-picked on top, they are technically
 not even on the github/tensorflow branch, but rather in a certain
-sense are a tag of a feature branch from master/tensorflow. So,
+sense are a tag of a feature branch from main/tensorflow. So,
 `git-bisect` doesn't even have a clear history to bisect on in
 multiple ways.
 
@@ -634,14 +634,14 @@ commits. We can compute this as so:
 
 Given that both tags were taken from the feature branch, the reader
 can prove to themselves that this commit is guaranteed to be on
-`github/tensorflow` and not `github/master` since all commits from
-`github/master` are forwarded using git merges.
+`github/tensorflow` and not `github/main` since all commits from
+`github/main` are forwarded using git merges.
 
 Then lets assume that we checked out `$TAG_MERGE_BASE` and then ran
 `test.sh` and did not hit any error. Ok, we can not bisect. Sadly,
 as mentioned above if we run git-bisect in between `$TAG_MERGE_BASE`
 and `tags/tag-tensorflow-bad`, `git-bisect` will sometimes choose
-commits from `github/master` which would cause `test.sh` to fail
+commits from `github/main` which would cause `test.sh` to fail
 if we are testing tensorflow specific code! To work around this
 problem, we need to start our bisect and then tell `git-bisect` to
 ignore those commits by using the skip sub command:

docs/DebuggingTheCompiler.md

@@ -1887,7 +1887,7 @@ the complex number type defined in the
 differentiable.
 [The full implementation is here](https://github.com/tensorflow/swift-apis/blob/main/Sources/third_party/Experimental/Complex.swift).
 The implementation adopts the
-[Autograd convention](https://github.com/HIPS/autograd/blob/master/docs/tutorial.md#complex-numbers)
+[Autograd convention](https://github.com/HIPS/autograd/blob/main/docs/tutorial.md#complex-numbers)
 for derivatives of functions with complex arguments or results, so that we can
 define derivatives for non-holomorphic primitives.
 
@@ -2106,7 +2106,7 @@ func foo<T: Differentiable, U, V: Differentiable>(
 ##### Examples
 
 The `ElementaryFunctions` protocol introduced in
-[SE-0246](https://github.com/apple/swift-evolution/blob/master/proposals/0246-mathable.md)
+[SE-0246](https://github.com/apple/swift-evolution/blob/main/proposals/0246-mathable.md)
 defines generic elementary functions, which are non-linear. By defining
 derivatives using the `@derivative` attribute for these protocol
 requirements in an extension, all conforming types now have differentiable
@@ -3202,7 +3202,7 @@ Parker Schuh, and Dimitrios Vytiniotis.
 [Bart Chrzaszcz]: https://github.com/bartchr808
 
 [swift-numerics]: https://github.com/apple/swift-numerics
-[SE-0229]: https://github.com/apple/swift-evolution/blob/master/proposals/0229-simd.md
-[SE-0233]: https://github.com/apple/swift-evolution/blob/master/proposals/0233-additive-arithmetic-protocol.md
-[SE-0246]: https://github.com/apple/swift-evolution/blob/master/proposals/0246-mathable.md
-[SE-0251]: https://github.com/apple/swift-evolution/blob/master/proposals/0251-simd-additions.md
+[SE-0229]: https://github.com/apple/swift-evolution/blob/main/proposals/0229-simd.md
+[SE-0233]: https://github.com/apple/swift-evolution/blob/main/proposals/0233-additive-arithmetic-protocol.md
+[SE-0246]: https://github.com/apple/swift-evolution/blob/main/proposals/0246-mathable.md
+[SE-0251]: https://github.com/apple/swift-evolution/blob/main/proposals/0251-simd-additions.md

docs/DifferentiableProgramming.md

@@ -27,7 +27,7 @@ There are a number of restrictions to the use of generics that fall out of the i
 
 ### Recursive protocol constraints (*)
 
-*This feature has been accepted in [SE-0157](https://github.com/apple/swift-evolution/blob/master/proposals/0157-recursive-protocol-constraints.md) and is tracked by [SR-1445](https://bugs.swift.org/browse/SR-1445).*
+*This feature has been accepted in [SE-0157](https://github.com/apple/swift-evolution/blob/main/proposals/0157-recursive-protocol-constraints.md) and is tracked by [SR-1445](https://bugs.swift.org/browse/SR-1445).*
 
 Currently, an associated type cannot be required to conform to its enclosing protocol (or any protocol that inherits that protocol). For example, in the standard library `SubSequence` type of a `Sequence` should itself be a `Sequence`:
 
@@ -77,7 +77,7 @@ There are a number of Swift declarations that currently cannot have generic para
 
 ### Generic typealiases
 
-*This feature has been accepted in [SE-0048](https://github.com/apple/swift-evolution/blob/master/proposals/0048-generic-typealias.md) and was released with Swift 3.*
+*This feature has been accepted in [SE-0048](https://github.com/apple/swift-evolution/blob/main/proposals/0048-generic-typealias.md) and was released with Swift 3.*
 
 Typealiases could be allowed to carry generic parameters. They would still be aliases (i.e., they would not introduce new types). For example:
 
@@ -114,7 +114,7 @@ Note: generic associatedtypes address many use cases also addressed by higher-ki
 
 ### Generic subscripts
 
-*This feature has been accepted in [SE-0148](https://github.com/apple/swift-evolution/blob/master/proposals/0148-generic-subscripts.md), was tracked by [SR-115](https://bugs.swift.org/browse/SR-115) and was released with Swift 4.*
+*This feature has been accepted in [SE-0148](https://github.com/apple/swift-evolution/blob/main/proposals/0148-generic-subscripts.md), was tracked by [SR-115](https://bugs.swift.org/browse/SR-115) and was released with Swift 4.*
 
 Subscripts could be allowed to have generic parameters. For example, we could introduce a generic subscript on a `Collection` that allows us to pull out the values at an arbitrary set of indices:
 
@@ -210,7 +210,7 @@ There are a number of minor extensions we can make to the generics system that d
 
 ### Arbitrary requirements in protocols (*)
 
-*This feature has been accepted in [SE-0142](https://github.com/apple/swift-evolution/blob/master/proposals/0142-associated-types-constraints.md) and was released with Swift 4.*
+*This feature has been accepted in [SE-0142](https://github.com/apple/swift-evolution/blob/main/proposals/0142-associated-types-constraints.md) and was released with Swift 4.*
 
 Currently, a new protocol can inherit from other protocols, introduce new associated types, and add new conformance constraints to associated types (by redeclaring an associated type from an inherited protocol). However, one cannot express more general constraints. Building on the example from "Recursive protocol constraints", we really want the element type of a `Sequence`'s `SubSequence` to be the same as the element type of the `Sequence`, e.g.,
 
@@ -226,7 +226,7 @@ Hanging the `where` clause off the associated type protocol is not ideal, but th
 
 ### Typealiases in protocols and protocol extensions (*)
 
-*This feature has been accepted in [SE-0092](https://github.com/apple/swift-evolution/blob/master/proposals/0092-typealiases-in-protocols.md) and was released with Swift 3.*
+*This feature has been accepted in [SE-0092](https://github.com/apple/swift-evolution/blob/main/proposals/0092-typealiases-in-protocols.md) and was released with Swift 3.*
 
 Now that associated types have their own keyword (thanks!), it's reasonable to bring back `typealias`. Again with the `Sequence` protocol:
 
@@ -253,7 +253,7 @@ var p3: Promise = getRandomPromise() // p3 has type Promise<Int, Error> due to t
 
 ### Generalized `class` constraints
 
-*This feature is a consequence of proposal [SE-0156](https://github.com/apple/swift-evolution/blob/master/proposals/0156-subclass-existentials.md) and was released with Swift 4.*
+*This feature is a consequence of proposal [SE-0156](https://github.com/apple/swift-evolution/blob/main/proposals/0156-subclass-existentials.md) and was released with Swift 4.*
 
 The `class` constraint can currently only be used for defining protocols. We could generalize it to associated type and type parameter declarations, e.g.,
 
@@ -322,7 +322,7 @@ Unlike the minor extensions, major extensions to the generics model provide more
 
 ### Conditional conformances (*)
 
-*This feature has been accepted in [SE-0143](https://github.com/apple/swift-evolution/blob/master/proposals/0143-conditional-conformances.md) and is implemented in Swift 4.2.*
+*This feature has been accepted in [SE-0143](https://github.com/apple/swift-evolution/blob/main/proposals/0143-conditional-conformances.md) and is implemented in Swift 4.2.*
 
 Conditional conformances express the notion that a generic type will conform to a particular protocol only under certain circumstances. For example, `Array` is `Equatable` only when its elements are `Equatable`:
 
@@ -496,7 +496,7 @@ extension Bag {
 
 ### Moving the `where` clause outside of the angle brackets (*)
 
-*Accepted in [SE-0081](https://github.com/apple/swift-evolution/blob/master/proposals/0081-move-where-expression.md) and  implemented in Swift 3.*
+*Accepted in [SE-0081](https://github.com/apple/swift-evolution/blob/main/proposals/0081-move-where-expression.md) and  implemented in Swift 3.*
 
 The `where` clause of generic functions comes very early in the declaration, although it is generally of much less concern to the client than the function parameters and result type that follow it. This is one of the things that contributes to "angle bracket blindness". For example, consider the `containsAll` signature above:
 
@@ -513,7 +513,7 @@ func containsAll<S: Sequence>(elements: S) -> Bool
 
 ### Renaming `protocol<...>` to `Any<...>` (*)
 
-*Accepted in [SE-0095](https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md) as "Replace `protocol<P1,P2>` syntax with `P1 & P2` syntax" and implemented in Swift 3.*
+*Accepted in [SE-0095](https://github.com/apple/swift-evolution/blob/main/proposals/0095-any-as-existential.md) as "Replace `protocol<P1,P2>` syntax with `P1 & P2` syntax" and implemented in Swift 3.*
 
 The `protocol<...>` syntax is a bit of an oddity in Swift. It is used to compose protocols together, mostly to create values of existential type, e.g.,
 
@@ -730,7 +730,7 @@ The generics system doesn't seem like a good candidate for a reduction in scope;
 
 ### Associated type inference
 
-*[SE-0108](https://github.com/apple/swift-evolution/blob/master/proposals/0108-remove-assoctype-inference.md), a proposal to remove this feature, was rejected.*
+*[SE-0108](https://github.com/apple/swift-evolution/blob/main/proposals/0108-remove-assoctype-inference.md), a proposal to remove this feature, was rejected.*
 
 Associated type inference is the process by which we infer the type bindings for associated types from other requirements. For example:
 

docs/GenericsManifesto.md

@@ -958,7 +958,7 @@ Swift enums.
 
 The concept of open enums was added in Swift 5 ([SE-0192 Handling Future
 Enum
-Cases](https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md)),
+Cases](https://github.com/apple/swift-evolution/blob/main/proposals/0192-non-exhaustive-enums.md)),
 but that proposal did not change the importing strategy of non-annotated C
 enums, in part because of source compatibility concerns. It might be still
 possible to change C enums to be imported as open Swift enums, but as the time

docs/HowSwiftImportsCAPIs.md

@@ -29,7 +29,7 @@ Library evolution was formally described in `SE-0260 <SE0260_>`_, but this
 document should be kept up to date as new features are added to the language.
 
 .. _library evolution: https://swift.org/blog/abi-stability-and-more/
-.. _SE0260: https://github.com/apple/swift-evolution/blob/master/proposals/0260-library-evolution.md
+.. _SE0260: https://github.com/apple/swift-evolution/blob/main/proposals/0260-library-evolution.md
 
 .. contents:: :local:
 
@@ -108,7 +108,7 @@ with a single app target are not forced to think about access control, anyone
 writing a bundled library should (ideally) not be required to use any of the
 annotations described below in order to achieve full performance.
 
-.. _SE0193: https://github.com/apple/swift-evolution/blob/master/proposals/0193-cross-module-inlining-and-specialization.md
+.. _SE0193: https://github.com/apple/swift-evolution/blob/main/proposals/0193-cross-module-inlining-and-specialization.md
 .. _Swift Package Manager: https://swift.org/package-manager/
 
 .. note::
@@ -210,7 +210,7 @@ any future use of the function must take this into account.
 Although they are not a supported feature for arbitrary libraries at this time,
 public `transparent`_ functions are implicitly marked ``@inlinable``.
 
-.. _transparent: https://github.com/apple/swift/blob/master/docs/TransparentAttr.md
+.. _transparent: https://github.com/apple/swift/blob/main/docs/TransparentAttr.md
 
 
 Restrictions on Inlinable Functions

docs/LibraryEvolution.rst

@@ -122,7 +122,7 @@ Both of these annotations are things the compiler already knows when a type is d
 
 The compiler actually has basic support for frozen classes, which allow stored properties to be accessed directly by offset from the class reference. There's no real reason why this can't be supported more generally, but confusion around *what's* being frozen and the rarity of wanting to make this promise anyway kept it out of [SE-0260][].
 
-[SE-0260]: https://github.com/apple/swift-evolution/blob/master/proposals/0260-library-evolution.md
+[SE-0260]: https://github.com/apple/swift-evolution/blob/main/proposals/0260-library-evolution.md
 
 
 # Generalized Availability Model