swiftlang · AnthonyLatsis · Jul 18, 2022 · Jul 12, 2022 · Jul 12, 2022 · Jul 12, 2022
diff --git a/docs/ABIStabilityManifesto.md b/docs/ABIStabilityManifesto.md
diff --git a/docs/Android.md b/docs/Android.md
@@ -7,8 +7,9 @@ device running Android or an emulator. This guide explains:
 1. How to run a simple "Hello, world" program on your Android device.
 2. How to run the Swift test suite on an Android device.
 
-If you encounter any problems following the instructions below, please file a
-bug using https://bugs.swift.org/.
+If you encounter any problems following the instructions below, please
+[file an issue](https://github.com/apple/swift/issues) and apply the "Android"
+label.
 
 ## FAQ
 

diff --git a/docs/CppInteroperability/CppInteroperabilityStatus.md b/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

diff --git a/docs/Driver.md b/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.
diff --git a/docs/DynamicCasting.md b/docs/DynamicCasting.md
@@ -36,7 +36,7 @@ Where possible, each section includes machine-verifiable _invariants_ that can b
 
 Casting an instance of a type to its own type will always succeed and return the original value unchanged.
 
-```
+```swift
 let a: Int = 7
 a is Int // true
 a as? Int // Succeeds
@@ -109,13 +109,13 @@ Note: The associated `_ObjectiveCType` is constrained to be a subtype of `AnyObj
 In particular, this mechanism is equally available to the Swift implementation of Foundation on non-Apple platforms and the Objective-C Foundation on Apple platforms.
 
 Example #1:  Foundation extends the `Array` type in the standard library with an `_ObjectiveCBridgeable` conformance to `NSArray`.  This allows Swift arrays to be cast to and from Foundation `NSArray` instances.
-```
+```swift
 let a = [1, 2, 3] // Array<Int>
 let b = a as? AnyObject // casts to NSArray
 ```
 
 Example #2:  Foundation also extends each Swift numeric type with an `_ObjectiveCBridgeable` conformance to `NSNumber`.
-```
+```swift
 let a = 1 // Int
 // After the next line, b is an Optional<AnyObject>
 // holding a reference to an NSNumber
@@ -151,7 +151,7 @@ Casting to and from optional types will transparently unwrap optionals as much a
 Note: For "Optional Injection" above, the requirement that `t` is a non-nil instance of `T` implies that either `T` is not an `Optional` or that `T` is `Optional` and `t` has the form `.some(u)`
 
 Examples
-```
+```swift
 // T and U are any two distinct types (possibly optional)
 // NO is any non-optional type
 let t: T
@@ -187,7 +187,7 @@ Note that "optional depth" here refers to the number of optional wrappers needed
 2. Otherwise, the value should inject with the greatest optional depth possible.
 
 Examples
-```
+```swift
 // Depth preservation
 // The `.none` here has type `T?` with optional depth 1
 let t1: T???? = .some(.some(.some(.none)))
@@ -220,14 +220,14 @@ The result will be a new array where each `Int` in the original array has been i
 
 However, if any component item cannot be cast, then the outer cast will also fail.
 For example, consider the following:
-```
+```swift
 let a: Array<Any> = [Int(7), "string"]
 a as? Array<Int> // Fails because "string" cannot be cast to `Int`
 ```
 
 Specifically, the casting operator acts for `Array` as if it were implemented as follows.
 In particular, note that an empty array can be successfully cast to any destination array type.
-```
+```swift
 func arrayCast<T,U>(source: Array<T>) -> Optional<Array<U>> {
   var result = Array<U>()
   for t in source {
@@ -249,7 +249,7 @@ Similar logic applies to `Set` and `Dictionary` casts.
 Note that the resulting `Set` or `Dictionary` may have fewer items than the original if the component casting operation converts non-equal items in the source into equal items in the destination.
 
 Specifically, the casting operator acts on `Set` and `Dictionary` as if by the following code:
-```
+```swift
 func setCast<T,U>(source: Set<T>) -> Optional<Set<U>> {
   var result = Set<U>()
   for t in source {
@@ -382,7 +382,7 @@ For example, its metatype is named `AnyHashable.Type` and it does not have an ex
 Any protocol definition (except those that include an `associatedtype` property or which makes use of the `Self` typealias) has an associated existential type named after the protocol.
 
 Specifically, assume you have a protocol definition
-```
+```swift
 protocol P {}
 ```
 
@@ -427,7 +427,7 @@ We call this type the "metatype of `T`".
 Technically, static variables or methods of a type belong to the `T.self` instance and are defined by the metatype of `T`:
 
 Example:
-```
+```swift
 struct S {
   let ivar = 2
   static let svar = 1
@@ -447,7 +447,7 @@ However, in the following cases the metatype has a different name:
 * As explained above, although `AnyHashable` behaves like an existential type in some respects, its metatype is called `AnyHashable.Type`.
 
 Example:
-```
+```swift
 // Metatype of a struct type
 struct S: P {}
 S.self is S.Type // always true
@@ -501,7 +501,7 @@ As with other existentials, casting _from_ an existential metatype is equivalent
 Casting _to_ an existential metatype succeeds whenever the source is a conforming metatype instance (or can be unwrapped to yield such a metatype instance).
 
 Example
-```
+```swift
 protocol P {
    var ivar: Int { get }
    static svar: Int { get }
@@ -532,15 +532,15 @@ This is equivalent to saying that `P.self` is an instance of `P.Type`.
 (Remember that `P.self` is always an instance of `P.Protocol`.)
 
 This is a concern for Swift because of the following construct, which attempts to invoke a generic `f` in a situation where the concrete instance clearly conforms to `P` but is represented as a `P` existential:
-```
+```swift
 func f<T:P>(t: T) { .. use t .. }
 let a : P = something
 f(a)
 ```
 This construct is valid only if `T` conforms to `P` when `T = P`; that is, if `P` self-conforms.
 
 A similar situation arises with generic types:
-```
+```swift
 struct MyGenericType<T: P> {
   init(_ value: T) { ... }
 }
@@ -591,7 +591,7 @@ These are some of the ways in which Swift 5.3 differs from the behavior describe
 
 * Casts for which the target type is "more Optional" than the static source type previously produced errors.  This disallowed all of the following: injecting an `Int` into an `Int?`, extracting an `Int?` from an opaque `Any` container, and casting an `Array<Int>` to an `Array<Int?>`. This document allows all of these.
 
-```
+```swift
 let a = 7
 // Swift 5.3: error: cannot downcast to a more optional type
 // Specification: returns true
@@ -609,7 +609,7 @@ c is Int?
 
 * An instance of a CoreFoundation type could sometimes be cast to a protocol defined on the companion Obj-C type and sometimes not.  To make the behavior consistent, we had to choose one; having such casts always succeed seems more consistent with the general dual nature of Obj-C/CF types.
 
-```
+```swift
 import Foundation
 protocol P {}
 extension NSString: P {}
@@ -625,7 +625,7 @@ print(b is P)
 
 * The Swift 5.3 compiler asserts attempting to cast a struct to AnyObject
 
-```
+```swift
 struct S {}
 let s = S()
 // Swift 5.3: Compiler crash (in asserts build)
@@ -635,7 +635,7 @@ s as? AnyObject
 
 * `NSNumber()` does not cast to itself via `as?` in unoptimized builds
 
-```
+```swift
 import Foundation
 let a = NSNumber()
 // true in 5.3 for optimized builds; false for unoptimized builds
@@ -644,7 +644,7 @@ print((a as? NSNumber) != nil)
 
 * `Optional<NSNumber>` does not project
 
-```
+```swift
 import Foundation
 let a: Optional<NSNumber> = NSNumber()
 // Swift 5.3: false
@@ -657,17 +657,17 @@ print(a as? NSNumber)
 
 * Casting `NSNumber()` to `Any` crashes at runtime
 
-```
+```swift
 import Foundation
 let a = NSNumber()
 // Swift 5.3: Runtime crash (both optimized and unoptimized builds)
 // Specification: Succeeds
 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
 
-```
+```swift
 import Foundation
 protocol P {}
 extension CFBitVector : P {
@@ -680,9 +680,9 @@ 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.
 
-```
+```swift
 protocol P {}
 class C: P {}
 let c: C? = C()
@@ -692,9 +692,9 @@ 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`
 
-```
+```swift
 struct MyError: Error { }
 let a: Any? = MyError()
 let b: Any = a
@@ -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
+```swift
+// 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"
@@ -716,23 +716,23 @@ print((x as? Int??)!)
 
 * `Error.self` does not fully self-conform
 
-```
+```swift
 // Swift 5.3: Prints "false"
 // Specification: prints "true"
 print(Error.self is Error.Type)
 ```
 
 * Objective-C protocol metatypes do not fully self-conform
 
-```
+```swift
 import Foundation
 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
 
-```
+```swift
 protocol P {}
 class Foo: P {}
 let optionalFoo: Foo? = Foo()

diff --git a/docs/GenericsManifesto.md b/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:
 

@@ -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 ..

diff --git a/docs/Lexicon.md b/docs/Lexicon.md
@@ -574,11 +574,11 @@ for flow-sensitive diagnostics, optimization, and LLVM IR generation.
 
 ## SR
 
-An issue reported on [bugs.swift.org](https://bugs.swift.org). A
-backronym for "Swift Report"; really the name is derived from LLVM's
-idiomatic use of "PR" ("Problem Report") for its bugs. We didn't go with
-"PR" for Swift because we wanted to be able to unambiguously reference
-LLVM bugs.
+An issue that was originally reported on the now-retired Jira instance that used
+to be located at [bugs.swift.org](https://bugs.swift.org). A backronym for
+"Swift Report"; really the name is derived from LLVM's idiomatic use of "PR"
+("Problem Report") for its bugs. We didn't go with "PR" for Swift because we
+wanted to be able to unambiguously reference LLVM bugs.
 
 ## stdlib