[Refactoring] Fix invalid legacy body for Result<Void, ...> handler

When adding an async alternative for a function with a
`(Result<Void, ...>) -> Void` completion handler, the legacy body was
adding a call to the handler with `.success(result)`. We don't assign to
`result` for `Void` handlers, so pass `()` instead.

Resolves rdar://81829392

Author: bnbarham

lib/IDE/Refactoring.cpp

@@ -7864,8 +7864,13 @@ class AsyncConverter : private SourceEntityWalker {
     }
     case HandlerType::RESULT: {
       if (!ResultName.empty()) {
-        OS << tok::period_prefix << "success" << tok::l_paren << ResultName
-           << tok::r_paren;
+        OS << tok::period_prefix << "success" << tok::l_paren;
+        if (!HandlerDesc.willAsyncReturnVoid()) {
+          OS << ResultName;
+        } else {
+          OS << tok::l_paren << tok::r_paren;
+        }
+        OS << tok::r_paren;
       } else {
         OS << tok::period_prefix << "failure" << tok::l_paren;
         addForwardedErrorArgument("error", HandlerDesc);

test/refactoring/ConvertAsync/basic.swift

@@ -475,6 +475,21 @@ func voidAndErrorCompletion(completion: @escaping (Void, Error?) -> Void) {}
 // VOID-AND-ERROR-HANDLER-NEXT: }
 // VOID-AND-ERROR-HANDLER: func voidAndErrorCompletion() async throws {}
 
+// RUN: %refactor-check-compiles -add-async-alternative -dump-text -source-filename %s -pos=%(line+1):1 | %FileCheck -check-prefix VOID-RESULT-HANDLER %s
+func voidResultCompletion(completion: @escaping (Result<Void, Error>) -> Void) {}
+// VOID-RESULT-HANDLER:      {
+// VOID-RESULT-HANDLER-NEXT:   Task {
+// VOID-RESULT-HANDLER-NEXT:     do {
+// VOID-RESULT-HANDLER-NEXT:       try await voidResultCompletion()
+// VOID-RESULT-HANDLER-NEXT:       completion(.success(()))
+// VOID-RESULT-HANDLER-NEXT:     } catch {
+// VOID-RESULT-HANDLER-NEXT:       completion(.failure(error))
+// VOID-RESULT-HANDLER-NEXT:     }
+// VOID-RESULT-HANDLER-NEXT:   }
+// VOID-RESULT-HANDLER-NEXT: }
+// VOID-RESULT-HANDLER:      func voidResultCompletion() async throws {
+
+
 // 2. Check that the various ways to call a function (and the positions the
 //    refactoring is called from) are handled correctly