[PATCH] D30210: [include-fixer] Add usage count to find-all-symbols.

Haojian Wu via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Thu Feb 23 07:58:38 PST 2017


hokein accepted this revision.
hokein added a comment.
This revision is now accepted and ready to land.

Thanks! Looks good from my side.

I'd wait to see whether @bkramer has more comments before commit it.



================
Comment at: include-fixer/find-all-symbols/SymbolInfo.h:50
+  // used. These are used to rank results.
+  struct Signals {
+    Signals() {}
----------------
hokein wrote:
> sammccall wrote:
> > hokein wrote:
> > > I think we can make a standalone class instead of making it a nested class of `SymbolInfo` because I don't see strong relationship between them. Maybe name it `FindingSignals` or `FindingInfo`.
> > The relationship between them is a strong scoping one: signals only make sense in the context of a particular SymbolInfo.
> > 
> > If it was a parallel top-level class, it needs a name that communicates this relationship, most likely SymbolSignals. I don't think that's significantly better than SymbolInfo::Signals.
> > 
> > (If I had my druthers, these would probably be Symbol and Symbol::Signals - the "info" is the main reason that SymbolInfo::Signals is noisy. But not worth the churn I think)
> > 
> You convinced me.  Please keep the comment of `Signals` updated.
> 
> > If I had my druthers, these would probably be Symbol and Symbol::Signals - the "info" is the main reason that SymbolInfo::Signals is noisy. But not worth the churn I think)
> 
> In the initial design, `SymbolInfo` merely represents a cpp symbol. But as more features developed, `SymbolInfo` might be not a good name at the moment. `Symbol` seems not a better name as LLVM already has many classes named `Symbol`. We can leave it here.
> 
> 
>  keep the comment of Signals updated.

You are missing this.


https://reviews.llvm.org/D30210





More information about the cfe-commits mailing list