kadircet wrote: > we've had users for whom the BuiltinHeaders: QueryDriver behaviour worked > better and want to switch back to it (examples here, here, here, here).
I'd argue that the fix isn't as simple as using builtin headers from a different toolchain for those users. Because clang itself (and I'd be surprised if gcc didn't) makes lots of assumptions about what compiler builtins are available, what predefined macros will be set etc. when parsing these builtin headers. So my worry is, by giving "some support" we'll actually create the impression that this should "work" for the users and create more confusion, which will turn into more complexity/maintenance burden in the project. e.g. right now people are getting file not found errors for such headers, going forward we'll just have different errors like declarations not being found, constants having unexpected values etc. Because gcc/clang will rely on different builtins being available. but, i won't block the change from going in. in the end, i don't know too much about gcc intrinsics, and maybe things will just work. i am happy to wait and see the outcome, but if we start getting more requests, i think before digging a deeper hole here we should really consider if we should. > @kadircet please feel free to yell at me if you disagree 😆 I completely agree about tests. It was solely meant as an "integration" test to make sure interaction works end to end. If we want to test more, I think we should do some restructring. At least move the output we're trying to "emulate" into a separate file so that it's clear what we're parsing. https://github.com/llvm/llvm-project/pull/129459 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
