Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang/lib/Tooling/Inclusions/HeaderIncludes.cpp | ||
---|---|---|
339–341 | instead of doing this unconditionally, can we do this until we find first include that looks like the main include? similarly we should also only look for main includes during ::insert if we didn't encounter one already during initial scan. this ensures we give users a way out (in certain cases) when there are multiple alternatives, by respecting the order they have. it's also aligned with the behaviour of sortCppIncludes, which is used when formatting files elsewhere. | |
clang/unittests/Tooling/HeaderIncludesTest.cpp | ||
146 | can you also have test cases with competing includes, eg: foo.cc, with contents: #include "zoo/foo.h" // insert "xoo/foo.h" -> xoo/foo.h doesn't become main include |
clang/lib/Tooling/Inclusions/HeaderIncludes.cpp | ||
---|---|---|
369–370 | sorry if I was unclear in the previous comment. but i was trying to say we should only consider includes we've encountered during the initial scan. getting different results depending on the order of insertions being performed is likely gonna cause confusion elsewhere (e.g. depending on the first diagnostic you've in clangd, you'll get different order of includes). hence, let's keep this function stateless (which also gets rid of the concerns around mutable) |
clang/lib/Tooling/Inclusions/HeaderIncludes.cpp | ||
---|---|---|
369–370 | sorry for misunderstanding your comment. Make it stateless looks like a good idea. |
instead of doing this unconditionally, can we do this until we find first include that looks like the main include? similarly we should also only look for main includes during ::insert if we didn't encounter one already during initial scan.
this ensures we give users a way out (in certain cases) when there are multiple alternatives, by respecting the order they have. it's also aligned with the behaviour of sortCppIncludes, which is used when formatting files elsewhere.