HighCommander4 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.
Thanks for the added thoughts. One thing we can do to help mitigate these concerns is add a disclaimer to the documentation of `BuiltinHeaders: QueryDriver`, that it's a "here be dragons" kind of option. (The patch is of course keeping `BuiltinHeaders: Clangd` as the **default**, and I think that's the right choice for exactly the reasons you outline.) 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
