[PATCH] D54404: Exclude matchers which can have multiple results

Stephen Kelly via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Mon Nov 19 02:15:43 PST 2018


steveire added inline comments.


================
Comment at: lib/ASTMatchers/Dynamic/Registry.cpp:624
+      "hasAnyDeclaration",
+      "hasAnyName",
+      "hasAnyParameter",
----------------
aaron.ballman wrote:
> steveire wrote:
> > sbenza wrote:
> > > I'm not sure what goes in this list.
> > > `hasAnyName` is here but not `hasName`.
> > > What is ambiguous about `hasAnyName`?
> > I have a follow-up which adds output showing that `hasName` can be used. See
> > 
> > http://ec2-52-14-16-249.us-east-2.compute.amazonaws.com:10240/z/_X9mnw
> > 
> > If there was an entry there for `hasAnyName`, what would go in it?
> > If there was an entry there for hasAnyName, what would go in it?
> 
> Presumably the same as `hasName()`, though for the purposes of that list, I could see why it would be a bit odd to list it.
> 
> It almost feels like this isn't about ambiguity of the matchers (at least, not always) so much as it is about sensibility within a "the following are related matchers" list due to there being many different ways for matchers to relate. For instance, a related matcher could be `functionDecl(hasAnyParameter(anything()))`, but you might not want to list that because it's an open-ended problem to generate all such cases and it has very limited value to list them. Is that a better way for me to think about this?
>  it is about sensibility ... Is that a better way for me to think about this?

Yes. The list attempts to exclude things that don't make sense to show for `matcher` output.


Repository:
  rC Clang

https://reviews.llvm.org/D54404





More information about the cfe-commits mailing list