We plan to reuse it in the include-cleaner library, this patch moves
this functionality from clangd to libtooling, so that this piece of code can be
shared among all clang tools.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang/include/clang/Tooling/Inclusions/Header.h | ||
---|---|---|
1 ↗ | (On Diff #474188) | rather than calling this Header can we call this HeaderAnalysis? |
21 ↗ | (On Diff #474188) | let's mention being #importd as well |
clang/lib/Tooling/Inclusions/Header.cpp | ||
64 ↗ | (On Diff #474188) | translateFile actually does a linear scan over all the slocentries, so i think it's better for this API to be based on FileID. (later on we can easily get fileentry from fileid in constant time) |
clang/unittests/Tooling/HeaderTest.cpp | ||
21 ↗ | (On Diff #474188) | can you also add a test case for #import ? |
clang/lib/Tooling/Inclusions/Header.cpp | ||
---|---|---|
64 ↗ | (On Diff #474188) | You can get content through the fileentry directly, no? |
clang/include/clang/Tooling/Inclusions/Header.h | ||
---|---|---|
21 ↗ | (On Diff #474188) | again comment seems to be the same. |
clang/lib/Tooling/Inclusions/Header.cpp | ||
64 ↗ | (On Diff #474188) | oh thanks for reminding that i forgot to mention it here, yes we can get that, but that would misbehave in the case of virtual/remapped files. so can you actually add a comment here about why we should get the contents from source manager? |
clang/unittests/Tooling/HeaderTest.cpp | ||
21 ↗ | (On Diff #474188) | this is marked as done, but i can't see any #import statements here. am i missing something? |
clang/lib/Tooling/Inclusions/Header.cpp | ||
---|---|---|
64 ↗ | (On Diff #474188) | But even when that remapping happens at the sourcemanager level, it happens on fileentries, not FileIDs (how would the latter even work?) So SM.getMemoryBufferForFileOrNone(FileEntry)? |
clang/lib/Tooling/Inclusions/Header.cpp | ||
---|---|---|
64 ↗ | (On Diff #474188) | oh i didn't know about getMemoryBufferForFileOrNone, looks like it should do.
i was just looking at contentcache, which is a 1:1 mapping for each FileID and has fileentries, one for the original file and the other for providing the contents (or a virtual buffer). i didn't notice the overrideinfo map was also exposed. |
getBufferData => getMemoryBufferForFileOrNone
clang/include/clang/Tooling/Inclusions/Header.h | ||
---|---|---|
21 ↗ | (On Diff #474188) | you're looking at the old version, this file has been renamed, please see the https://reviews.llvm.org/D137697. |
clang/include/clang/Tooling/Inclusions/HeaderAnalysis.h | ||
---|---|---|
29 | oops sorry, missed this part. the idea with using getmemorybuffer was to use fileentries here. |
@hokein it seems the unit test wasn't updated for the last-minute API change, which breaks check-all for me. I've posted https://reviews.llvm.org/D137927, could you take a look if that change is correct?
oops, thanks, and your analysis is right! (I landed a fix in 5c4ae8a86a865e622e2c663666c0c139334b5da2 before reading your email, sorry).
No worries, thanks for fixing so quickly! I just happened to pull in the wrong moment...
oops sorry, missed this part. the idea with using getmemorybuffer was to use fileentries here.