docs: Migrate from SR issues to GitHub issues

docs/CppInteroperability/CppInteroperabilityStatus.md

@@ -76,7 +76,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 (https://bugs.swift.org/browse/SR-15956) |
+| Inline Namespaces                           | Yes, with some known issues ([#58217](https://github.com/apple/swift/issues/58217)) |
 | Exceptions                                  | No  |
 | Fields                                      | Yes |
 | Member functions                            | Yes. Some value category overloads aren't imported |
@@ -120,7 +120,7 @@ This status table describes which of the following C++ standard library features
 ## Known Issues
 
 ### Inline Namespaces
-- https://bugs.swift.org/browse/SR-15956: 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/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
 
 
 ## Swift to C++ Interoperability Status

docs/Driver.md

@@ -167,10 +167,8 @@ The output file map accepts other entries, but they should not be considered
 stable. Please stick to what's shown here.
 
 (Note: In the example output file map above, all of the per-file outputs are
-being emitted to the same directory. [SR-327][] covers adding a flag that would
-infer this behavior given a directory path.)
-
-  [SR-327]: https://bugs.swift.org/browse/SR-327
+being emitted to the same directory. [#42949](https://github.com/apple/swift/issues/42949)
+covers adding a flag that would infer this behavior given a directory path.)
 
 
 ## Whole-Module Optimization ##
@@ -286,9 +284,10 @@ past that, so:
      import later.
 
      If you want debugging that's more than `-gline-tables-only`, this is the
-     only supported way to do it today. ([SR-2637][] and [SR-2660][] are aimed
-     at improving on this.) On the plus side, this mode doesn't strictly need
-     an output file map if you give up incremental builds.
+     only supported way to do it today [apple/llvm-project#4588](https://github.com/apple/llvm-project/issues/4588)
+     and [#45265](https://github.com/apple/swift/issues/45265) are aimed at
+     improving on this). On the plus side, this mode doesn't strictly need an
+     output file map if you give up incremental builds.
 
    - Invoke `swiftc -c`, then pass the resulting object files to your linker.
      All the same options from above apply, but you'll have to manually deal
@@ -302,10 +301,8 @@ past that, so:
 _Can I link all the object files together in the same binary, even if they came
 from multiple modules?_
 
-This is not currently supported, and debugging probably won't work. (See
-[SR-2637][] and [SR-2660][] for more details.) However, if you are using
-`-gnone` or `-gline-tables-only`, the worst you will suffer is more symbols
-being visible than are strictly necessary.
-
-  [SR-2637]: https://bugs.swift.org/browse/SR-2637
-  [SR-2660]: https://bugs.swift.org/browse/SR-2660
+This is not currently supported, and debugging probably won't work (see
+[apple/llvm-project#4588](https://github.com/apple/llvm-project/issues/4588) and
+[#45265](https://github.com/apple/swift/issues/45265) for more details).
+However, if you are using `-gnone` or `-gline-tables-only`, the worst you will
+suffer is more symbols being visible than are strictly necessary.

docs/DynamicCasting.md

@@ -665,7 +665,7 @@ let a = NSNumber()
 print(a is Any)
 ```
 
-* SR-2289: CF types cannot be cast to protocol existentials
+* [#44896](https://github.com/apple/swift/issues/44896): CF types cannot be cast to protocol existentials
 
 ```
 import Foundation
@@ -680,7 +680,7 @@ extension CFBitVector : P {
 print(CFBitVector.makeImmutable(from: [10,20]) is P)
 ```
 
-* SR-4552: Cannot cast `Optional<T> as Any` to protocol type.  Note that this is a particular problem for reflection with weak fields, since `Mirror` reflects those as `Any` containing an `Optional` value.
+* [#47129](https://github.com/apple/swift/issues/47129): Cannot cast `Optional<T> as Any` to protocol type.  Note that this is a particular problem for reflection with weak fields, since `Mirror` reflects those as `Any` containing an `Optional` value.
 
 ```
 protocol P {}
@@ -692,7 +692,7 @@ let a = c as? Any
 print(a is P)
 ```
 
-* SR-8964: `Any` containing `Optional<Any>` cannot cast to `Error`
+* [#51469](https://github.com/apple/swift/issues/51469): `Any` containing `Optional<Any>` cannot cast to `Error`
 
 ```
 struct MyError: Error { }
@@ -703,10 +703,10 @@ let b: Any = a
 print(b is Error)
 ```
 
-* SR-6126: Inconsistent results for nested optionals
+* [#48681](https://github.com/apple/swift/issues/48681): Inconsistent results for nested optionals
 
 ```
-// Note: SR-6126 includes many cases similar to the following
+// Note: This issue includes many cases similar to the following
 let x: Int? = nil
 print(x as Int??) // ==> "Optional(nil)"
 // Swift 5.3: prints "nil"
@@ -730,7 +730,7 @@ let a = NSObjectProtocol.self
 print(a is NSObjectProtocol.Type)
 ```
 
-* SR-1999: Cannot cast `Any` contents to a protocol type
+* [#44608](https://github.com/apple/swift/issues/44608): Cannot cast `Any` contents to a protocol type
 
 ```
 protocol P {}

docs/GenericsManifesto.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/main/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 [#44054](https://github.com/apple/swift/issues/44054).*
 
 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`:
 
@@ -43,7 +43,7 @@ The compiler currently rejects this protocol, which is unfortunate: it effective
 
 ### Nested generics
 
-*This feature was tracked by [SR-1446](https://bugs.swift.org/browse/SR-1446) and was released with Swift 3.1.*
+*This feature was tracked by [#44055](https://github.com/apple/swift/issues/44055) and was released with Swift 3.1.*
 
 Currently, a generic type cannot be nested within another generic type, e.g.
 
@@ -57,7 +57,7 @@ There isn't much to say about this: the compiler simply needs to be improved to
 
 ### Concrete same-type requirements
 
-*This feature was tracked by [SR-1009](https://bugs.swift.org/browse/SR-1009) and was released with Swift 3.1.*
+*This feature was tracked by [#43621](https://github.com/apple/swift/issues/43621) and was released with Swift 3.1.*
 
 Currently, a constrained extension cannot use a same-type constraint to make a type parameter equivalent to a concrete type. 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/main/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 [#42737](https://github.com/apple/swift/issues/42737) 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:
 

docs/HowToGuides/GettingStarted.md

@@ -85,7 +85,7 @@ toolchain as a one-off, there are a couple of differences:
    **Note:** If you've already forked the project on GitHub at this stage,
    **do not clone your fork** to start off. We describe
    [how to setup your fork](#setting-up-your-fork) in a subsection below.
-   <!-- Recommending against cloning the fork due to SR-13476 and SR-13505. -->
+   <!-- Recommending against cloning the fork due to https://github.com/apple/swift/issues/55918 and https://github.com/apple/swift/issues/55947. -->
 3. Double-check that `swift`'s sibling directories are present.
    ```sh
    ls ..

docs/StringManifesto.md

@@ -1022,10 +1022,11 @@ domain-specific language (just write ordinary swift code!) and its type safety
 problems (put the data right where it belongs!) but the following issues prevent
 it from being useful for localized formatting (among other jobs):
 
-  * [SR-2303](https://bugs.swift.org/browse/SR-2303) We are unable to restrict
-    types used in string interpolation.
-  * [SR-1260](https://bugs.swift.org/browse/SR-1260) String interpolation can't
-    distinguish (fragments of) the base string from the string substitutions.
+  * [#44910](https://github.com/apple/swift/issues/44910): We are unable to
+    restrict types used in string interpolation.
+  * [#43868](https://github.com/apple/swift/issues/43868): String interpolation
+    can't distinguish (fragments of) the base string
+    from the string substitutions.
 
 In the long run, we should improve Swift string interpolation to the point where
 it can participate in most any formatting job.  Mostly this centers around