[docs] Update links to repositories moved to https://github.com/swiftlang/

Author: lamtrinhdev

Diff for: docs/ABIStabilityManifesto.md

@@ -26,7 +26,7 @@ framework module.
 _**Warning**_
 
 This document has not yet been updated for
-[SE-0117](https://github.com/apple/swift-evolution/blob/main/proposals/0117-non-public-subclassable-by-default.md),
+[SE-0117](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0117-non-public-subclassable-by-default.md),
 which adds the \"open\" level of access.
 
 ## Rules

Diff for: docs/AccessControl.md

@@ -8,7 +8,7 @@ device running Android or an emulator. This guide explains:
 2. How to run the Swift test suite on an Android device.
 
 If you encounter any problems following the instructions below, please
-[file an issue](https://github.com/apple/swift/issues) and apply the "Android"
+[file an issue](https://github.com/swiftlang/swift/issues) and apply the "Android"
 label.
 
 ## FAQ

Diff for: docs/Android.md

@@ -93,6 +93,6 @@ Some branches are *automerged* into other branches, to keep them in sync. This i
 To update the Branch/Tag requirements, please follow these steps:
 
   1. Create pull requests to update the branch/tag in the following repositories:
-     - in `apple/swift` modify [`update-checkout-config.json`](https://github.com/apple/swift/blob/main/utils/update_checkout/update-checkout-config.json)
-     - in `apple/swift-source-compat-suite` repository modify [`common.py`](https://github.com/apple/swift-source-compat-suite/blob/main/common.py)
+     - in `swiftlang/swift` modify [`update-checkout-config.json`](https://github.com/swiftlang/swift/blob/main/utils/update_checkout/update-checkout-config.json)
+     - in `swiftlang/swift-source-compat-suite` repository modify [`common.py`](https://github.com/swiftlang/swift-source-compat-suite/blob/main/common.py)
   1. Notify @shahmishal after creating the pull requests

Diff for: docs/Branches.md

@@ -244,7 +244,7 @@ These commands will:
 3. Compare the obtained data to the baseline (stored in git) and HEAD (version of a compiler built without the PR changes)
 4. Report the results in a pull request comment
 
-For the detailed explanation of how compiler performance is measured, please refer to [this document](https://github.com/apple/swift/blob/main/docs/CompilerPerformance.md).
+For the detailed explanation of how compiler performance is measured, please refer to [this document](https://github.com/swiftlang/swift/blob/main/docs/CompilerPerformance.md).
 
 ## Cross Repository Testing
 
@@ -254,7 +254,7 @@ For example:
 
 ```
 Please test with following pull request:
-https://github.com/apple/swift/pull/4574
+https://github.com/swiftlang/swift/pull/4574
 
 @swift-ci Please test Linux platform
 ```

Diff for: docs/ContinuousIntegration.md

@@ -2,7 +2,7 @@
 
 # ⚠️ Warning: document is out of date. ⚠️
 
-**This document has not had significant updates in the last three years. The goals and design outlined here do not necessarily reflect those established by the C++ Interop Work Group. For an up-to-date document, please see [the Forward Vision document](https://github.com/apple/swift-evolution/blob/main/visions/using-swift-from-c%2B%2B.md).**
+**This document has not had significant updates in the last three years. The goals and design outlined here do not necessarily reflect those established by the C++ Interop Work Group. For an up-to-date document, please see [the Forward Vision document](https://github.com/swiftlang/swift-evolution/blob/main/visions/using-swift-from-c%2B%2B.md).**
 
 [** ‼️ Additionally, the official C++ interoperability documentation is live at Swift.org and provides an up-to-date guide for mixing Swift and C++ ‼️ **](https://www.swift.org/documentation/cxx-interop/)
 
@@ -280,7 +280,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/main/proposals/0176-enforce-exclusive-access-to-memory.md).
+Memory](https://github.com/swiftlang/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
@@ -1810,7 +1810,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/main/proposals/0176-enforce-exclusive-access-to-memory.md)):
+Memory](https://github.com/swiftlang/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
@@ -2881,7 +2881,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/main/proposals/0253-callable.md)).
+types](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0253-callable.md)).
 
 ```c++
 // C++ header.
@@ -3476,7 +3476,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/main/clang/lib/APINotes).
+Clang](https://github.com/swiftlang/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.
 

Diff for: docs/CppInteroperability/CppInteroperabilityManifesto.md

@@ -77,7 +77,7 @@ This status table describes which of the following C++ language features can be
 | Typedefs / Type aliases                     | Yes    |
 | Global Variables                            | Yes    |
 | Namespaces                                  | Yes    |
-| Inline Namespaces                           | Yes, with some known issues ([#58217](https://github.com/apple/swift/issues/58217)) |
+| Inline Namespaces                           | Yes, with some known issues ([#58217](https://github.com/swiftlang/swift/issues/58217)) |
 | Exceptions                                  | No. Uncaught exceptions that propagate into Swift frames are UB.  |
 | Fields                                      | Yes |
 | Member functions                            | Yes. Some value category overloads aren't imported |
@@ -121,7 +121,7 @@ This status table describes which of the following C++ standard library features
 ## Known Issues
 
 ### Inline Namespaces
-- [#58217](https://github.com/apple/swift/issues/58217): Swift's typechecker currently doesn't allow calling a function from an inline namespace when it's referenced through the parent namespace. Example of a test that fails: https://github.com/apple/swift/blob/main/test/Interop/Cxx/namespace/inline-namespace-function-call-broken.swift
+- [#58217](https://github.com/swiftlang/swift/issues/58217): Swift's typechecker currently doesn't allow calling a function from an inline namespace when it's referenced through the parent namespace. Example of a test that fails: https://github.com/swiftlang/swift/blob/main/test/Interop/Cxx/namespace/inline-namespace-function-call-broken.swift
 
 
 ## Swift to C++ Interoperability Status

Diff for: docs/CppInteroperability/CppInteroperabilityStatus.md

@@ -195,6 +195,6 @@ CxxInterop.main()
 - To generate an Xcode project run `cmake -GXcode`
 - To generate with Ninja run `cmake -GNinja`
 
-- For more information on `cmake` see the  'GettingStarted' documentation: (https://github.com/apple/swift/blob/main/docs/HowToGuides/GettingStarted.md)
+- For more information on `cmake` see the  'GettingStarted' documentation: (https://github.com/swiftlang/swift/blob/main/docs/HowToGuides/GettingStarted.md)
 
 

Diff for: docs/CppInteroperability/GettingStartedWithC++Interop.md

@@ -830,7 +830,7 @@ For more information and a high level example, see:
 
 When bisecting it might be necessary to run the `update-checkout` script
 each time you change shas. To do this you can pass `--match-timestamp`
-to automatically checkout match the timestamp of the `apple/swift` repo
+to automatically checkout match the timestamp of the `swiftlang/swift` repo
 across the other repos.
 
 ## Disabling PCH Verification
@@ -859,7 +859,7 @@ such configuration.
 # Debugging the Compiler Driver
 
 The Swift compiler uses a standalone compiler-driver application written in
-Swift: [swift-driver](https://github.com/apple/swift-driver). When building the
+Swift: [swift-driver](https://github.com/swiftlang/swift-driver). When building the
 compiler using `build-script`, by default, the standalone driver will be built
 first, using the host toolchain, if the host toolchain contains a Swift
 compiler. If the host toolchain does not contain Swift, a warning is emitted and
@@ -870,7 +870,7 @@ is updated with a symlink to the standalone driver, ensuring calls to the build
 directory's `swift` and `swiftc` always forward to the standalone driver.
 
 For more information about the driver, see:
-[github.com/apple/swift-driver/blob/main/README.md](https://github.com/apple/swift-driver/blob/main/README.md)
+[github.com/swiftlang/swift-driver/blob/main/README.md](https://github.com/swiftlang/swift-driver/blob/main/README.md)
 
 ## Swift Compiler Driver F.A.Q.
 > What's the difference between invoking 'swiftc' vs. 'swift-driver' at the top
@@ -883,7 +883,7 @@ by examining the invoked program's name. The compiler frontend can be invoked
 directly by invoking the `swift-frontend` executable, or passing in the
 `-frontend` option to `swiftc`.
 
-The standalone [Compiler Driver](https://github.com/apple/swift-driver) is
+The standalone [Compiler Driver](https://github.com/swiftlang/swift-driver) is
 installed as a separate `swift-driver` executable in the Swift toolchain's `bin`
 directory. When a user launches the compiler by invoking `swiftc`, the C++ based
 compiler executable forwards the invocation to the `swift-driver` executable if
@@ -905,7 +905,7 @@ become symbolic links to the `swift-driver` executable directly.
 > Will 'swiftc ... -###' always print the same set of commands for the old/new
   driver? Do they call 'swift-frontend' the same way?
 
-The standalone [Compiler Driver](https://github.com/apple/swift-driver) is meant
+The standalone [Compiler Driver](https://github.com/swiftlang/swift-driver) is meant
 to be a direct drop-in replacement for the C++-based legacy driver. It has the
 exact same command-line interface. The expectation is that its behaviour closely
 matches the legacy driver; however, during, and after the transition to the new

Diff for: docs/DebuggingTheCompiler.md

@@ -110,7 +110,7 @@ Educational notes should:
 Adding new educational notes is a great way to get familiar with the process of contributing to Swift, while also making a big impact!
 
 To add a new educational note:
-1. Follow the [directions in the README](https://github.com/apple/swift#getting-sources-for-swift-and-related-projects) to checkout the Swift sources locally. Being able to build the Swift compiler is recommended, but not required, when contributing a new note.
+1. Follow the [directions in the README](https://github.com/swiftlang/swift#getting-sources-for-swift-and-related-projects) to checkout the Swift sources locally. Being able to build the Swift compiler is recommended, but not required, when contributing a new note.
 2. Identify a diagnostic to write an educational note for. To associate an educational note with a diagnostic name, you'll need to know its internal identifier. The easiest way to do this is to write a small program which triggers the diagnostic, and run it using the `-debug-diagnostic-names` compiler flag. This flag will cause the internal diagnostic identifier to be printed after the diagnostic message in square brackets.
 3. Find any closely related diagnostics. Sometimes, what appears to be one diagnostic from a user's perspective may have multiple variations internally. After determining a diagnostic's internal identifier, run a search for it in the compiler source. You should find:
     - An entry in a `Diagnostics*.def` file describing the diagnostic. If there are any closely related diagnostics the note should also be attached to, they can usually be found nearby.