ilya-biryukov wrote: > @ilya-biryukov unfortunately it seems that the reproducer is very sensitive > to the exact clang revision.
I should have clarified this better. It **does not** reproduce for me either with this example, but it's the exact code (and module structure) that causes the issue with our internal build system. I'm still trying to figure out which details I'm missing. > The warning/error about "inline function not defined" is very familiar to me > and I'm reducing it now in our code... I can confirm, we're definitely seeing a lot of them too when shaking up the build graph or seeing other Clang changes. This probably just surfaces some other error that we were lucky to avoid. > In your example strong_int.h is not a part of its own module so clang merges > it and it causes issue for friend inside template class. Right, and the different deserialization order is probably causing this error to resurface. This is actually a supported use-case for modules (it's possible to get the same effect with global module fragment in C++20 modules) and modularizing all functions that define these widely-used friend functions (like `AbslHashValue`) might be tough on our side. My intuition is that we'd rather help fixing the underlying issues than go through this big refactoring for the whole codebase. Although, we'd need to see how hard that would be. So far, I'm still focused on getting a proper repro and understanding what's going on exactly. After we have that, we can see whether fixing it is on the table. https://github.com/llvm/llvm-project/pull/111992 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
