================ @@ -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:
I am guessing that the MLIR location type doesn't have any notion of multiple nested locations due to macro expansions. So we can't represent the full complexity of macros here. The outermost location seems like the right one to choose. (I am not familiar with either the Clang location type or the MLIR location type, so I welcome being corrected here.) https://github.com/llvm/llvm-project/pull/113483 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits