sammccall added a comment. (sorry i thought i sent these comments earlier)
This is a change to clang rather than clangd, so it affects the behavior of the compiler and other clang-based tools. While it might do something useful in clangd, I'm skeptical of its general applicability because with this extension we do not expect that such files will be parseable. I think the evidence you've found is that editors (e.g. clangd!) should handle these files, but not necessarily compilers. > one has to add #include "header.hpp" at the top of .inl files to make it work > but thats not a big deal. It may not be a big burden to add it to code that you own, but making the compiler misinterpret other people's code where this #include isn't present can be a problem. I think ideally we'd express this behavior at the clangd level instead. Something like "we suspect this file contains $LANGUAGE, so if the compile flags/extension don't imply anything particular, treat it that way". As well as being less intrusive, this is a more general, useful feature: - LSP allows the editor to specify the language, typically based in editor UI, so this would give the user control over whether such files were treated as C/C++/ObjC/ObjC++ etc rather than hard-coding C++. (We can still have a default). - this needn't be specific to suffix ".inl". LLVM uses ".inc", I'm sure other codebases use other extensions. (And the reason i never sent the comment is i couldn't come to a conclusion on the best way to do this inside clangd. Needs some more thought...) 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
