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

[David Olsen 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());
+}
----------------
dkolsen-pgi wrote:

Diagnostics that happen during CIR code generation will use the Clang `SourceLocation` because the Clang AST is still available.  But later passes won't have access to a `SourceLocation`.  Every MLIR node already has an `mlir::Location`.  Storing a `SourceLocation` instead of, or in addition to, an `mlir::Location` is not practical.

I don't expect many diagnostics to be issued from CIR when compilation.  Virtually all diagnostics of interest should have been issued during parsing and semantic checking.  The answer may be different when CIR is used for static analysis.  I'll let the static analysis experts sort that out.

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