jcking1034 marked an inline comment as not done. jcking1034 added inline comments.
================ Comment at: clang/docs/LibASTMatchersReference.html:636 -<tr><td>Matcher<<a href="https://clang.llvm.org/doxygen/classclang_1_1Decl.html";>Decl</a>></td><td class="name" onclick="toggle('blockDecl0')"><a name="blockDecl0Anchor">blockDecl</a></td><td>Matcher<<a href="https://clang.llvm.org/doxygen/classclang_1_1BlockDecl.html";>BlockDecl</a>>...</td></tr> +<tr><td>Matcher<<a href="https://clang.llvm.org/doxygen/classclang_1_1Decl.html";>Decl</a>></td><td class="name" onclick="toggle('blockDecl0')"><a name="blockDecl0Anchor">blockDecl</a></td><td>Matcher<BlockDecl>...</td></tr> <tr><td colspan="4" class="doc" id="blockDecl0"><pre>Matches block declarations. ---------------- ymandel wrote: > ymandel wrote: > > Here and below. These changes look wrong. Did the script encounter an error? > Any luck fixing these edits? I think I got it to work! ================ Comment at: clang/include/clang/ASTMatchers/ASTMatchers.h:6361-6362 +/// \endcode +/// qualifiedTypeLoc(hasUnqualifiedLoc(pointerTypeLoc())) +/// matches the `TypeLoc` of the variable declaration of `x`, but not `y`. +AST_MATCHER_P(QualifiedTypeLoc, hasUnqualifiedLoc, TypeLocMatcher, ---------------- aaron.ballman wrote: > I'm trying to reason my way through this. You want to match a qualified type > location and `int * const` matches that. Then you want it to match an > unqualified type loc and `int` matches that. Then it should be a pointer > type... but `int` does not match that. So I wouldn't expect `x` to be > matched. What have I misunderstood? The `hasUnqualifiedLoc` will actually be matched by `int *` (the `*` is part of the unqualified `TypeLoc`), which will then be a pointer `TypeLoc` that can be matched by `pointerTypeLoc`. Thus, the `TypeLoc` of `x` should be matched. I just realized that the unit test `BindsToConstVolatilePointerVarDecl` which covers a similar situation is broken, where the match is producing a false positive (probably matching some hidden boiler plate code) - I've gone ahead and fixed the test, which hopefully clarifies things. I'll also add a unit test for these cases, as well. ================ Comment at: clang/include/clang/ASTMatchers/ASTMatchers.h:6406-6414 +/// Matches reference `TypeLoc`s. +/// +/// Given +/// \code +/// int x = 3; +/// int& xx = x; +/// \endcode ---------------- aaron.ballman wrote: > I'd appreciate more documentation on whether this is expected to match both > lvalue and rvalue references. I suppose there's a secondary question of > whether this matches member functions too: > ``` > struct S { > void func() &; // Can this match this as a reference type loc? > }; > ``` I've added an example to clarify that this matches both lvalue and rvalue references. Having some trouble addressing your second point, but will keep playing around with it. ================ Comment at: clang/include/clang/ASTMatchers/ASTMatchers.h:6510-6520 +/// Matches elaborated `TypeLoc`s. +/// +/// Given +/// \code +/// class C {}; +/// class C c; +/// \endcode ---------------- aaron.ballman wrote: > It'd be helpful to document how this behaves in C where the tag needs to be > used (unlike in C++ where the tag can be elided unless you want an elaborated > type). Same below. This matcher should match in C, I've updated the comment to reflect this. I've also updated the unit test `ElaboratedTypeLocTest_BindsToElaboratedStructDeclaration` to cover both the C and C++ cases. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D111242/new/ https://reviews.llvm.org/D111242 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
