sr-tream wrote: > apart from technical details like the threading concerns and reliance on > certain variants that we don't really have (eg order of includes); at a high > level the idea of "finding a representative source file for the header and > replicating the PP state" is hard to work in general. > > The current approach of finding a candidate through `HeaderIncluders` will > pick an arbitrary source file that transitively includes the header you're > interested in. Hence you'll actually create a set of `-include XX` commands, > that **might** (and probably will) recursively include the header itself. > Also there's nothing detecting a failure in processing of the compilation > unit, this is done without checking self-containedness (which is again hard > to check) hence will definitely regress both performance and correctness for > self-contained headers as well.
We can limit ourselves to only the paired source file, and cancel inclusions if the source file does not include a non-self-contained header directly. This will reduce the number of situations in which this hack works, but will avoid the problems you describe https://github.com/llvm/llvm-project/pull/72479 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
