ArcsinX added a comment. In D107304#2921588 <https://reviews.llvm.org/D107304#2921588>, @kadircet wrote:
> I am not sure this is a good idea. Surely we can go with this approach and > pretend to have the same GNUC version as the toolchain, but we are still > using clang underneath as @joerg pointed out and we might not be able to > parse language/compiler extensions supported by GNU compilers, which will > lead to confusion. The most confusing thing for me that we already have this implicitly set `-fgnuc-version=4.2.1`. So, we already have implicitly set `__GNUC__` and other GCC macros as a default behavior. > I think in such cases people should just have a `.clangd` file in their repo > that adds `-fgnuc-version=x.y.z` to compile flags, i.e: > > CompileFlags: > Add: -fgnuc-version=x.y.z > > This will be a more explicit step taken by the user, hence they'll be more > likely to know why clangd is not behaving the way they want it to. Sometimes it's not an easy task to understand that errors in diagnostics returned by clangd are the result of incorrect `__GNUC__` value (in many projects it's not just `#error ...`). Also it's not convenient to use `.clangd` config in this case: - change compiler version => update `.clangd` - several build directories (e.g. native and cross with different GCC versions). - idea was to make it in more automatic way. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D107304/new/ https://reviews.llvm.org/D107304 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
