================
@@ -52,10 +62,33 @@ class CIRGenModule : public CIRGenTypeCache {
/// A "module" matches a c/cpp source file: containing a list of functions.
mlir::ModuleOp theModule;
+ clang::DiagnosticsEngine &diags;
+
const clang::TargetInfo ⌖
public:
+ mlir::ModuleOp getModule() const { return theModule; }
+
+ /// Helpers to convert Clang's SourceLocation to an MLIR Location.
----------------
AaronBallman wrote:
I don't know the details about CIR, so it's hard for me to say for certain.
Maybe an example will help tease this out? Given:
```
#define ten 10
#define foo(x) (x + ten)
int y = foo(12);
```
you get source locations like: https://godbolt.org/z/oG7fq9b1K Notice how you
get `Loc=<<source>:3:9 <Spelling=<source>:2:16>>` or similar where the source
location of the final expanded token and the spelling location of where the
pre-preprocessed token lives are different -- which location does MLIR expect
to work with? It could work with the spelling location (where tokens physically
reside in the source file), or it could work with the expansion locations
(where the tokens logically reside in the source file after preprocessing), or
it could be ambivalent about which form it uses and will happily work with
whatever.
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
