Preparation for D108194.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang-tools-extra/clangd/Headers.h | ||
---|---|---|
116 | this concept needs documentation. | |
116 | there's a naming issue here:
What do you think about just ID, which would be spelled from the outside as IncludeStructure::ID? | |
116–130 | this public member is now sandwiched between methods | |
118 | "Name" certainly needs to be clarified here. | |
125 | it's unclear from this patch whether you want to expose the whole graph or just allow querying per-file - I doubt we need both. | |
125 | tests? | |
139–141 | The public interface now uses the File abstraction, so this method sticks out. (It has an awkward interface in the first place due to the need to use strings) Suggest replacing it with DenseMap<File, unsigned> includeDepth(File Root). We'd need to add StringRef RealPath(File) for the caller, but that seems to make sense anyway. | |
151 | this isn't abstract :-) also the public nature of it isn't used, in this patch at least. | |
152 | File should be capitalized. FWIW, for a private method I prefer the old name here |
I resolved the comments we discussed offline, there's a weird SIGSEGV (out of boundary error) somewhere in the tests but it looks fine otherwise.
Do you want to wrap the unsigned in a struct to make it slightly safer, but more complicated to use?
Just nits left really.
I like this idea, though it's probably not a huge deal either way.
(I marginally prefer enum class HeaderID : unsigned {}; over a struct, but it's basically the same thing)
clang-tools-extra/clangd/CodeComplete.cpp | ||
---|---|---|
1382–1398 | this isn't the ID of the include structure, it's the ID of the main file | |
1383 | IncludeStructure is mutable here, I think it'd be safe to getOrCreate here. Alternatively, make this infallible having IncludeStructure record the HeaderID for the main file in its constructor, and just use Includes.Root here. Either way, I'd rather not deal with Expected<> error handling at runtime if we can define this error away. | |
clang-tools-extra/clangd/Headers.h | ||
116–130 | As mentioned offline, this is an implementation comment, but it doesn't say *what the HeaderID is*. Suggest something like: HeaderID identifies file in the include graph. It corresponds to a FileEntry rather than a FileID, but stays stable across preamble & main file builds. I'd move this impl comment back down to the private StringMap, but it could also follow the description. | |
119 | comment still refers to "file index" as if it were introducing a term we use elsewhere | |
125 | I think this can be Optional rather than Expected - much more lightweight. | |
129 | this should be an assertion (or just leave that up to the vector) - passing an out-of-range HeaderID is invalid | |
138–139 | comment is out of date | |
140 | getName() is not right here. | |
144 | we don't need this method if IncludeChildren is exposed, right? |
clang-tools-extra/clangd/Headers.cpp | ||
---|---|---|
172 | no auto here. I really hope this isn't std::string :-) Actually I think you can avoid extracting this variable at all, because the !RealPathName.empty() check is redundant. The case where both sides are empty is rare enough that it's fine to assign as long as the *stored* name is empty. | |
174 | extract std::string &RealPathName = RealPathNames[...]? | |
189 | This is a "can't happen" condition - remove or replace with an assert? | |
202–203 | This is no longer true, we don't need the check. | |
clang-tools-extra/clangd/Headers.h | ||
116–130 | This doesn't seem to be done. A reader rather needs complete self-contained description of the concept at the *top*, optionally followed by an explanation about the implementation (separated by a blank line). | |
clang-tools-extra/clangd/unittests/HeadersTests.cpp | ||
70 | reparsing the code several times to obtain header IDs doesn't seem reasonable. It's surprising behavior from a test helper, and it requires that header IDs are stable across parses! Can we just pass in the IncludeStructure instead? | |
236 | Why are we asserting on every element of the map one at a time, instead of the whole map at once? Seems like it would be more regular and easier to read. I'd probably just write: DenseMap<HeaderID, SmallVector<HeaderID>> Expected = { ... }; EXPECT_EQ(Expected, Includes.IncludeChildren); | |
238 | EXPECT_THAT(foo.empty()) -> EXPECT_THAT(foo, IsEmpty()). | |
clang-tools-extra/clangd/unittests/ParsedASTTests.cpp | ||
511–513 | The ratio of setup to punchline of the rest of this test seems like it's gotten out of hand (it wasn't great before, but it's doubled). What about just auto &FM = PatchedAST->getSourceManager().getFileManager(); auto &Includes = PatchedAST->getIncludeStructure(); auto MainID = Includes.getID(FM.getFile(testPath("foo.cpp"))); auto AuxID = Includes.getID(FM.getFile(testPath("sub/aux.h"))); EXPECT_THAT(Includes.IncludeChildren.at(MainID), Contains(AuxID)); It tests a bit less I guess, but seems like enough | |
568–571 | and here |
Resolve all but two comments, leave the clarification questions for these two.
clang-tools-extra/clangd/Headers.cpp | ||
---|---|---|
202–203 | Wait, why not? We still have unresolved includes, e.g. preamble patches are like that, their RealPathNames stay empty. | |
clang-tools-extra/clangd/unittests/HeadersTests.cpp | ||
236 | This would expect the elements in the map to be in a particular order, isn't this something we don't want? |
clang-tools-extra/clangd/Headers.cpp | ||
---|---|---|
202–203 | Right, but why do we need to filter them out here? | |
clang-tools-extra/clangd/unittests/HeadersTests.cpp | ||
236 | == on DenseMap doesn't consider order. If you mean the order within map values (i.e. lists of child edges): these are in the order the #includes appear in the file, which seems fine to depend on to me |
Switch to full DenseMap comparison in the tests.
clang-tools-extra/clangd/Headers.cpp | ||
---|---|---|
202–203 | I feel like producing them in the first place is kind of redundant, what signal does it give to the user through such API? Getting some "hidden"/"unresolved" includes certainly feels rather confusing to me, post-filtering outside probably requires understanding of the internals which does not look like a good idea. WDYT? | |
clang-tools-extra/clangd/unittests/HeadersTests.cpp | ||
236 | Yes, I initially meant the SmallVector order, but yeah, this seems reasonable, thank you! |
Looks like this breaks tests on Windows: http://45.33.8.238/win/45971/step_9.txt
PTAL!
IncludeStructure is mutable here, I think it'd be safe to getOrCreate here.
Alternatively, make this infallible having IncludeStructure record the HeaderID for the main file in its constructor, and just use Includes.Root here.
Either way, I'd rather not deal with Expected<> error handling at runtime if we can define this error away.