[PATCH] D19876: Add an AST matcher for string-literal length

[Etienne Bergeron via cfe-commits]

etienneb added a comment.

Other opinions?
I'll proceed to the cleanup if no one else has comments.


================
Comment at: include/clang/ASTMatchers/ASTMatchers.h:1575
@@ +1574,3 @@
+/// \code
+///   char *s = "abcd"; wchar_t *ws = L"abcd";
+///   char *t = "a";
----------------
aaron.ballman wrote:
> etienneb wrote:
> > aaron.ballman wrote:
> > > Split these onto two lines?
> > If I look around, it seems to be more consistent to keep it on the same line (line 1563)
> > 
> > ```
> > ///   char *s = "abcd"; wchar_t *ws = L"abcd";
> > ```
> > 
> > ```
> > ///   int array[4] = {1}; vector int myvec = (vector int)(1, 2);
> > ```
> > 
> > ```
> > ///   char ch = 'a'; wchar_t chw = L'a';
> > ``
> I don't have a strong opinion on it; however, since these get turned into examples that are on the website, I would weakly prefer the examples not be hideous. :-P
Ditto. No strong opinion.
But, I like consistency. I'm willing to fix all other instances too.

================
Comment at: include/clang/ASTMatchers/ASTMatchers.h:1578
@@ +1577,3 @@
+/// \endcode
+AST_MATCHER_P(StringLiteral, lengthIs, unsigned, N) {
+  return Node.getLength() == N;
----------------
aaron.ballman wrote:
> etienneb wrote:
> > etienneb wrote:
> > > aaron.ballman wrote:
> > > > Perhaps we can adjust the `hasSize()` matcher instead? It currently works with ConstantArrayType, but it seems reasonable for it to also work with StringLiteral.
> > > I didn't like the term "size" as it typically refer to the size in bytes.
> > > Which is not the same for a wide-string.
> > > 
> > > Now, there is two different convention for naming matchers:
> > >   hasLength   and  lengthIs  ?
> > > 
> > > Any toughs on that?
> > > 
> > > 
> > Here is the matcher for hasSize
> > ```
> > AST_MATCHER_P(ConstantArrayType, hasSize, unsigned, N) {
> >   return Node.getSize() == N;
> > }
> > ```
> > 
> > It's getting the getSize attribute. I believe we should stick with the name of the attribute.
> > But, I'm not sure if we should use hasLength, or lengthIs.
> I'm not too worried about size vs length (for instance, std::string has both). I would imagine this being implemented the same way we do other things with variance in API but not concept. See GetBodyMatcher in ASTMatchersInternal.h (and others near there) as an example.
> 
> I prefer hasSize because the two concepts are quite similar. For instance, a string literal's type is of a constant array type already.
I do not have strong opinion too on the naming. I'm curious if others also has opinion on it?
Then, I'll proceed.


http://reviews.llvm.org/D19876