matts1 wrote: Thanks for the review, what you said makes sense. This is extremely important for us that we can get this to work though, so I was wondering if there was some way we could work around it. I'll use the `rtti` flag for all future examples.
Firstly, to check that I understand correctly, essentially the only thing that compiling a PCH file does is to generate an AST and export some symbols, so literally the only thing that compiling a module with `-frtti` vs `-fno-rtti` would do is that one the former would parse with `__cpp_rtti` defined. So from what I can tell, you would end up with the following compilation steps: ``` clang++ ... -o mod_a.pcm clang++ ... -fmodule-file mod_a.pcm -o mod_b.pcm clang++ -fmodule-file mod_a.pcm -fmodule_file mod_b.pcm -o <binary/object file> ``` The first and second's `-frtti` would decide whether the macro was enabled in their specific parts of the AST, and the third's `-frtti` would determine whether to actually enable RTTI in the codegen. I believe it's extremely justified to disallow a module compiled with RTTI to depend on one without (and vice versa), by default. However, I'm currently trying to understand if there's a specific harm from allowing this when you have the `-Wno-module-file-config-mismatch`. https://github.com/llvm/llvm-project/pull/131569 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
