nridge added inline comments.
================
Comment at: clang-tools-extra/clangd/index/Relation.cpp:19
+llvm::iterator_range<RelationSlab::iterator>
+RelationSlab::lookup(const SymbolID &Subject,
+ index::SymbolRole Predicate) const {
----------------
kadircet wrote:
> I would suggest adding another version which returns all the relations a
> given `Subject` participates, but I suppose currently we don't have any use
> cases.
>
> Feel free to add or skip, that can be added when necessary.
I'd rather add this when a use case arises.
================
Comment at: clang-tools-extra/clangd/index/Relation.h:52
+
+class RelationSlab {
+public:
----------------
kadircet wrote:
> I believe `RelationSlab` should still be immutable, even after the `build`
> operation below `RelationSlab` is mutable.
> Let's introduce the builder class and move mutating operations and build into
> it. So that it would be more symmetric to other slabs we have.
>
> Also are there any use-cases requiring RelationSlab to be mutable?
I'm not aware of any use-cases requiring it to be mutable. I'm making it
immutable as suggested.
================
Comment at: clang-tools-extra/clangd/index/Relation.h:89
+private:
+ RelationSlab(std::vector<Relation> Relations)
+ : Relations(std::move(Relations)) {}
----------------
kadircet wrote:
> Do we really need this?
I think so. The builder needs a way to construct the slab. Aggregate
initialization doesn't work because the class already has declared default and
copy constructors.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D59407/new/
https://reviews.llvm.org/D59407
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
