Improve heuristic for extending return value with "on failure" info (#…

…1096)

Sources/SwiftDocC/Model/ParametersAndReturnValidator.swift

@@ -364,8 +364,8 @@ struct ParametersAndReturnValidator {
             }
         }
 
-        if returns.contents.contains(where: { $0.format().lowercased().contains("error") }) {
-            // If the existing returns value documentation mentions "error" at all, don't add anything
+        if returns.possiblyDocumentsFailureBehavior() {
+            // If the existing returns value documentation appears to describe the failure / error behavior, don't add anything
             return nil
         }
         if signatures[.objectiveC]?.returns == [.init(kind: .typeIdentifier, spelling: "BOOL", preciseIdentifier: "c:@T@BOOL")] {
@@ -664,6 +664,24 @@ struct ParametersAndReturnValidator {
 
 // MARK: Helper extensions
 
+private extension Return {
+    /// Applies a basic heuristic to give an indication if the return value documentation possibly documents what happens when an error occurs
+    func possiblyDocumentsFailureBehavior() -> Bool {
+        contents.contains(where: { markup in
+            let formatted = markup.format().lowercased()
+
+            // Check if the authored markup contains one of a handful of words as an indication that it possibly documents what happens when an error occurs.
+            return returnValueDescribesErrorRegex.firstMatch(in: formatted, range: NSRange(formatted.startIndex ..< formatted.endIndex, in: formatted)) != nil
+        })
+    }
+}
+
+/// A regular expression that finds the words; "error", "fail", "fails", "failure", "failures", "nil", and "null".
+/// These words only match at word boundaries or when surrounded by single backticks ("`").
+///
+/// This is used as a heuristic to give an indication if the return value documentation possibly documents what happens when an error occurs.
+private let returnValueDescribesErrorRegex = try! NSRegularExpression(pattern: "(\\b|`)(error|fail(ure)?s?|nil|null)(\\b|`)", options: .caseInsensitive)
+
 private extension SymbolGraph.Symbol.FunctionSignature {
     mutating func merge(with signature: Self, selector: UnifiedSymbolGraph.Selector) {
         // An internal helper function that compares parameter names

Sources/docc/DocCDocumentation.docc/documenting-api-with-different-language-representations.md → Sources/docc/DocCDocumentation.docc/Documenting API with different language representations/documenting-api-with-different-language-representations.md

@@ -38,7 +38,7 @@ When a symbol has different parameters or return values in different source lang
 ```objc
 /// - Parameters:
 ///   - someValue: Some description of this parameter.
-///   - error: On output, a pointer to an error object that describes why "doing somehting" failed, or `nil` if no error occurred.
+///   - error: On output, a pointer to an error object that describes why "doing something" failed, or `nil` if no error occurred.
 /// - Returns: `YES` if "doing something" was successful, `NO` if an error occurred.
 - (BOOL)doSomethingWith:(NSInteger)someValue
                   error:(NSError **)error;
@@ -52,12 +52,73 @@ func doSomething(with someValue: Int) throws
 
 Because the Swift representation of this method only has the "someValue" parameter and no return value, DocC hides the "error" parameter documentation and the return value documentation from the Swift version of this symbol's page.
 
+@Row {
+  @Column {
+    ![](params-1-swift)    
+  }
+  @Column {
+    ![](params-1-objc)
+  }    
+}
 
-You don't need to document the Objective-C representation's "error" parameter or Objective-C specific return value for symbols defined in Swift.
-DocC automatically adds a generic description for the "error" parameter and extends your return value documentation to describe the Objective-C specific return value behavior. 
-
-If you want to customize this documentation you can manually document the "error" parameter and return value. 
+You don't need to document the Objective-C representation's "error" parameter or the Objective-C specific return value for methods that correspond to throwing functions in Swift.
+DocC automatically adds a generic description for the "error" parameter for the Objective-C version of that symbol's page. 
+If you want to customize this documentation you can manually document the "error" parameter.
 Doing so won't change the Swift version of that symbol's page.
-DocC will still hide the parameter and return value documentation that doesn't apply to each source language's version of that symbol's page.
+
+When the Swift representation returns `Void`---which corresponds to a `BOOL` return value in Objective-C (like in the example above)---DocC adds a generic description of the `BOOL` return value to the Objective-C version of that symbol's page. 
+
+@Row {
+  @Column {
+    ![](params-2-swift)    
+  }
+  @Column {
+    ![](params-2-objc)
+  }    
+}
+
+When the Swift representation returns a value---which corresponds to a `nullable` return value in Objective-C---DocC extends your return value documentation, for the Objective-C version of that symbol's page, to describe that the methods returns `nil` if an error occurs unless your documentation already covers this behavior. 
+For example, consider this throwing function in Swift and its corresponding Objective-C interface:
+
+**Swift definition**
+
+```swift
+/// - Parameters:
+///   - someValue: Some description of this parameter.
+/// - Returns: Some general description of this return value.
+@objc func doSomething(with someValue: Int) throws -> String
+```
+
+**Generated Objective-C interface**
+
+```objc
+- (nullable NSString *)doSomethingWith:(NSInteger)someValue
+                                 error:(NSError **)error;
+```
+
+For the Swift representation, with one parameter and a non-optional return value,
+DocC displays the "someValue" parameter documentation and return value documentation as-is.
+For the Objective-C representation, with two parameters and a nullable return value,
+DocC displays the "someValue" parameter documentation, generic "error" parameter documentation, and extends the return value documentation with a generic description about the Objective-C specific `nil` return value when the method encounters an error. 
+
+@Row {
+  @Column {
+    ![](params-3-swift)    
+  }
+  @Column {
+    ![](params-3-objc)
+  }    
+}
+
+> Tip:
+> If you document the Objective-C specific `nil` return value for a method that corresponds to a throwing function in Swift,
+> but don't provide more information to the reader than "On failure, this method returns `nil`", 
+> consider removing that written documentation to let DocC display its generic description about the Objective-C specific `nil` return value, 
+> only on the Objective-C version of that symbol's page.
+
+The return value documentation you write displays on both the Swift and Objective-C versions of that symbol's page.
+DocC won't add its generic `nil` return value description to the Objective-C page, 
+if your return value documentation already describes that the method returns `nil` when it fails or encounters an error,
+but that Objective-C specific documentation you've written will display on the Swift version of that page where the symbol has a non-optional return type.
 
 <!-- Copyright (c) 2024 Apple Inc and the Swift Project authors. All Rights Reserved. -->