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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
