[clang] [CIR] Call code gen; create empty cir.func op (PR #113483)

[Aaron Ballman via cfe-commits]

================
@@ -24,9 +27,140 @@ CIRGenModule::CIRGenModule(mlir::MLIRContext &context,
                            clang::ASTContext &astctx,
                            const clang::CodeGenOptions &cgo,
                            DiagnosticsEngine &diags)
-    : astCtx(astctx), langOpts(astctx.getLangOpts()),
-      theModule{mlir::ModuleOp::create(mlir::UnknownLoc())},
-      target(astCtx.getTargetInfo()) {}
+    : builder(&context), astCtx(astctx), langOpts(astctx.getLangOpts()),
+      theModule{mlir::ModuleOp::create(mlir::UnknownLoc::get(&context))},
+      diags(diags), target(astCtx.getTargetInfo()) {}
+
+mlir::Location CIRGenModule::getLoc(SourceLocation cLoc) {
+  assert(cLoc.isValid() && "expected valid source location");
+  const SourceManager &sm = astCtx.getSourceManager();
+  PresumedLoc pLoc = sm.getPresumedLoc(cLoc);
+  StringRef filename = pLoc.getFilename();
+  return mlir::FileLineColLoc::get(builder.getStringAttr(filename),
+                                   pLoc.getLine(), pLoc.getColumn());
+}
----------------
AaronBallman wrote:

>  It is wanting ClangIR to play nicely with the rest of the MLIR ecosystem, when many dialects are mixed together in a single tree later in the compilation chain, that makes using SourceLocation problematic.

However, that's also an internal implementation detail that doesn't need to be exposed to users of the CIR library. Clang works in `SourceLocation`; if CIR needs to work in something else, that should be abstracted away from the user. Still not saying this needs to be solved as part of this patch, but `CIRGenModule::getLoc()` are public interfaces currently; can those be made private so we're not leaking an implementation detail of CIR to users?

> But later passes won't have access to a SourceLocation.

Two things:

1) Diagnostics that depend on optimization levels have massive usability issues, so diagnostics from later passes strikes me as a potential design concern to start with; hopefully we don't end up in that situation except in very rare circumstances.
2) The backend does occasionally need to issue user-facing diagnostics (things like `__attribute__((error))` come to mind) and this has been a huge source of pain because LLVM does a pretty bad job of tracking source location with sufficient fidelity for Clang to have good QoI. If MLIR has the same issues, that should be something the MLIR folks work to correct before we transition to CIR as a default.

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