[clang] [clang][DebugInfo] Attach `DISubprogram` to additional call variants (PR #166202)

[J. Ryan Stinnett via cfe-commits]

================
@@ -6277,6 +6277,21 @@ RValue CodeGenFunction::EmitCall(const CGFunctionInfo &CallInfo,
     pushDestroy(QualType::DK_nontrivial_c_struct, Ret.getAggregateAddress(),
                 RetTy);
 
+  if (CalleeDecl) {
+    // Generate function declaration DISuprogram in order to be used
+    // in debug info about call sites.
+    if (CGDebugInfo *DI = getDebugInfo()) {
+      CodeGenFunction CalleeCGF(CGM);
----------------
jryans wrote:

I am definitely not a Clang code gen expert, so I tried to sort how to get the `CodeGenFunction` by looking around the codebase. 

>From looking around at other usages, it seems to me that new instances of `CodeGenFunction` are created on-demand like this to hold per-function code gen state when emitting constructors, blocks, and other more specialised functions (e.g. `ItaniumCXXABI::getOrCreateVirtualFunctionPointerThunk`). There are also some code gen AST visitors that hold a `CodeGenFunction` as they walk through expressions to emit, but I don't see how to make use of that here.

Constructing a `CodeGenFunction` sets up some pointers to a code gen builder, debug info state, etc. I think it's okay to create one for the callee like this, but again I am not an expert here.

The `CurGD` member of `CodeGenFunction` is used several functions called by `CodeGenFunction::BuildFunctionArgList`. This only happens for various `CXX*Decl` types, which is why the previous code didn't need to consider this.

Instead of creating a new `CodeGenFunction`, we _could_ temporarily change `this->CurGD` to point at the callee, and then reset it back... I just didn't see that pattern in use elsewhere, so I wasn't sure if it might confuse / violate some constraint.

https://github.com/llvm/llvm-project/pull/166202