Added static creators that create complete instances of SymbolInfo.
Diff Detail
Event Timeline
include-fixer/find-all-symbols/SymbolInfo.h | ||
---|---|---|
98–101 | To some degree this looks like we actually want a class hierarchy. But currently only ClassSymbolInfo is used? |
Not sure whether this is what @klimek expected..
You also need to update the FindAllSymbolsTests code (there is a CreateSymbolInfo function there).
include-fixer/find-all-symbols/SymbolInfo.cpp | ||
---|---|---|
91 | code indentation. | |
105 | A extra blank line. | |
115 | The same. | |
include-fixer/find-all-symbols/SymbolInfo.h | ||
99 | Use llvm::StringRef instead of std::string&. |
include-fixer/find-all-symbols/SymbolInfo.h | ||
---|---|---|
98–101 | At this point yes, since Symbolnfo is only created in InMemoryXrefsDB and FindAllSymbols now, and it is not trivial to change FindAllSymbols to use these creators. But one immediate use case I can foresee is converting proto buffer SymbolInfo to clang SymbolInfo when integrating with Google3 XrefsDB. |
include-fixer/find-all-symbols/SymbolInfo.h | ||
---|---|---|
98–101 | I think at this point YAGNI applies and we shouldn't create stuff that we don't use yet - code generally starts to rot when it's not used ;) |
Use static creator functions in SymbolInfo in FindAllSymbolTests, and make SymbolInfo::operator== compare all fields.
- Use static creator functions in SymbolInfo in FindAllSymbolTests, and make SymbolInfo::operator== compare all fields.
unittests/include-fixer/find-all-symbols/FindAllSymbolsTests.cpp | ||
---|---|---|
91–92 | You can remove it now. |
include-fixer/find-all-symbols/SymbolInfo.h | ||
---|---|---|
98–101 | So, multiple thoughts:
|
include-fixer/find-all-symbols/SymbolInfo.h | ||
---|---|---|
98–101 | But this change would also affect the way SymbolInfo is constructed in FindAllSymbol - class members are retrieved from AST in different locations, and we'd need to store fields in many temp variables, which might be troublesome in this case as well as some other cases. With a struct implementation plus static creatrors, we can have some flexibility. But I'm not sure if this makes sense from design perspective. |
Use llvm::StringRef instead of std::string&.