aaron.ballman added a comment. In D67025#3665301 <https://reviews.llvm.org/D67025#3665301>, @abbaswasim wrote:
>> FWIW, I did a search over github repos and this file extension is used, but >> I would hardly call it a common practice > > Fair enough. what would be sufficient evidence? I'm not certain we have any sort of agreed-upon measure for it. Personally, I'd want to see evidence that several other programming tools also treat the extension the same way. I notice that MSVC's file open dialog considers .inl to be a "Visual C++ File" and its save dialog considers .inl to be a "C++ Header File", so that's a good sign. I also notice that TextPad also considers .inl to be a C/C++ file (doesn't distinguish between language or what kind of file though). Does XCode have something similar? Notepad++ or other text editors? If so, I think that qualifies as sufficient evidence. > I think in general whether its `.inl` or any other extension thats used to > separate template implementations out of a header needs a solution. I have > started using `.hh` as a workaround but it not being a complete translation > unit is still a problem. And clangd also complains about recursive includes > in the .hh file. I've seen: .inc, .def, .hh,, and .H all within the past few years but in each case, it meant roughly the same thing "source that gets included but isn't intended as a stand-alone header file" (though I've certainly seen .H and .hh used to mean "C++ header file" as opposed to "C header file"). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D67025/new/ https://reviews.llvm.org/D67025 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
