This is an archive of the discontinued LLVM Phabricator instance.

Added XrefsDBManager into include-fixer and made XrefsDB return SymbolInfo.
ClosedPublic

Authored by ioeric on May 3 2016, 7:39 AM.

Diff Detail

Repository
rL LLVM

Event Timeline

ioeric updated this revision to Diff 55995.May 3 2016, 7:39 AM
ioeric retitled this revision from to Added XrefsDBManager into include-fixer..
ioeric updated this object.
ioeric retitled this revision from Added XrefsDBManager into include-fixer. to Added XrefsDBManager into include-fixer and made XrefsDB return SymbolInfo..
ioeric updated this object.
ioeric added a subscriber: cfe-commits.
klimek added inline comments.May 3 2016, 8:39 AM
include-fixer/InMemoryXrefsDB.cpp
18 ↗(On Diff #55995)

I'd make that a const ref.

24–26 ↗(On Diff #55995)

I assume it's intentional that SymbolInfo doesn't have a constructor; what's the reasoning behind that?

include-fixer/IncludeFixer.h
34 ↗(On Diff #55995)

Why wouldn't we still use the interface here? (usually we want to take the least specific type we can deal with)

ioeric updated this revision to Diff 56026.May 3 2016, 11:01 AM
ioeric marked an inline comment as done.
  • Addressed reviewer comment.
include-fixer/InMemoryXrefsDB.cpp
24–26 ↗(On Diff #55995)

SymbolInfo can be of different kinds, e.g. Function, Class etc. and has optional fields. I think this was the reason we didn't have a constructor for it. @hokein, right?

include-fixer/IncludeFixer.h
34 ↗(On Diff #55995)

XrefsDBManager now provides a different interface. XrefsDB provides std::vector<SymbolInfo> search(...), while XrefsDBManager provides std::vector<std::string> search(...), which just returns the #include paths.

klimek added inline comments.May 3 2016, 12:11 PM
include-fixer/IncludeFixer.h
34–35 ↗(On Diff #56026)

That seems unexpected. Why is the XrefsDBManager in the business of doing SymbolInfo -> include path mappings?

ioeric added inline comments.May 3 2016, 12:31 PM
include-fixer/IncludeFixer.h
34–35 ↗(On Diff #56026)

Since the mapping was done in XrefsDB before, I kept the way it was. Migrating SymbolInfo -> Include path mappings into IncludeFixer will be the next step, and I'll need to discuss with Ben about where exactly we want to place it.

hokein added inline comments.May 4 2016, 12:52 AM
include-fixer/InMemoryXrefsDB.cpp
24–26 ↗(On Diff #56026)

Yeah, the intention is that it's not easy to construct a completed instance at one time since it has many fields.

klimek accepted this revision.May 4 2016, 1:12 AM
klimek edited edge metadata.

lg

include-fixer/InMemoryXrefsDB.cpp
24–26 ↗(On Diff #56026)

Overall, I think creating an instance and then setting members should only be done from places very strongly coupled to the class.
Generally, I think in these cases creating static members of the class that construct the objects from the various data sources you have (like in this case from a string, and a vector<string>) are preferable; not necessary to address this in this CL, but please add a FIXME.

(also, specifically regarding the comment that it's not easy to construct a completed instance: that is a large hint that it should be encoded somewhere close to the class)

include-fixer/IncludeFixer.h
34–35 ↗(On Diff #56026)

Please add a FIXME that this is going to change.

unittests/include-fixer/IncludeFixerTest.cpp
86 ↗(On Diff #56026)

identifiers

This revision is now accepted and ready to land.May 4 2016, 1:12 AM
ioeric updated this revision to Diff 56104.May 4 2016, 1:26 AM
ioeric marked 8 inline comments as done.
ioeric edited edge metadata.
  • Added FIXMEs and fixed a nit.
This revision was automatically updated to reflect the committed changes.