[PATCH] D110386: [clangd] Refactor IncludeStructure: use File (unsigned) for most computations

[Sam McCall via Phabricator via cfe-commits]

sammccall added inline comments.


================
Comment at: clang-tools-extra/clangd/Headers.cpp:205
           CurrentLevel.push_back(Child);
-          const auto &Name = RealPathNames[Child];
           // Can't include files if we don't have their real path.
+          if (!RealPathNames[static_cast<unsigned>(Child)].empty())
----------------
kbobyrev wrote:
> sammccall wrote:
> > This is no longer true, we don't need the check.
> Wait, why not? We still have unresolved includes, e.g. preamble patches are like that, their `RealPathName`s stay empty.
Right, but why do we need to filter them out here?
Can't we just drop them when we use them to seed the proximity sources?


================
Comment at: clang-tools-extra/clangd/unittests/HeadersTests.cpp:234
+  auto Includes = collectIncludes();
+  EXPECT_THAT(Includes.IncludeChildren[getID(MainFile)],
+              UnorderedElementsAreArray({getID(FooHeader), getID(BarHeader)}));
----------------
kbobyrev wrote:
> sammccall wrote:
> > 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);
> > ```
> This would expect the elements in the map to be in a particular order, isn't this something we don't want?
`==` 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


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D110386/new/

https://reviews.llvm.org/D110386