This is an archive of the discontinued LLVM Phabricator instance.

Add an AST matcher for string-literal length
ClosedPublic

Authored by etienneb on May 3 2016, 10:51 AM.

Details

Summary

This patch is adding support for a matcher to check string literal length.

This matcher is used in clang-tidy checkers and is part of this refactoring:

see: http://reviews.llvm.org/D19841

Diff Detail

Event Timeline

etienneb updated this revision to Diff 56024.May 3 2016, 10:51 AM
etienneb retitled this revision from to Add an AST matcher for string-literal length.
etienneb updated this object.
etienneb added a subscriber: cfe-commits.
aaron.ballman added inline comments.May 3 2016, 12:33 PM
include/clang/ASTMatchers/ASTMatchers.h
1576

Split these onto two lines?

1579

Perhaps we can adjust the hasSize() matcher instead? It currently works with ConstantArrayType, but it seems reasonable for it to also work with StringLiteral.

etienneb added inline comments.May 3 2016, 8:32 PM
include/clang/ASTMatchers/ASTMatchers.h
1579

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?

Aaron? could you comment on it?

include/clang/ASTMatchers/ASTMatchers.h
1576

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';
``
1579

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.

aaron.ballman added inline comments.May 4 2016, 11:20 AM
include/clang/ASTMatchers/ASTMatchers.h
1576

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

1579

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.

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

include/clang/ASTMatchers/ASTMatchers.h
1576

Ditto. No strong opinion.
But, I like consistency. I'm willing to fix all other instances too.

1579

I do not have strong opinion too on the naming. I'm curious if others also has opinion on it?
Then, I'll proceed.

etienneb added inline comments.May 6 2016, 8:18 AM
include/clang/ASTMatchers/ASTMatchers.h
1579

For instance, a string literal's type

stringLiteral is matching an expression and not a type.
And, hasSize is currently applied on types.
Do we want this?

etienneb updated this revision to Diff 56423.May 6 2016, 9:15 AM

merging hasSize

etienneb updated this revision to Diff 56425.May 6 2016, 9:28 AM

fix unittests

Aaron? minus re-generation of the doc.
Is that what you want to see?

note: returned types for both getLength are not the same (APInt vs unsigned int).
I took the 'hasSize'-Matcher approach to let overloaded operators do the job for dispatching types.

note: there is a unittest for top-level node that is no longer valid because stringLiteral can be a top-level node now.

alexfh removed a reviewer: alexfh.May 10 2016, 8:22 AM
alexfh added a subscriber: alexfh.
aaron.ballman edited edge metadata.May 10 2016, 8:29 AM

Aaron? minus re-generation of the doc.
Is that what you want to see?

Yes, this is the direction I was hoping for, thank you!

note: returned types for both getLength are not the same (APInt vs unsigned int).
I took the 'hasSize'-Matcher approach to let overloaded operators do the job for dispatching types.

Perfect!

note: there is a unittest for top-level node that is no longer valid because stringLiteral can be a top-level node now.

Thank you for that explanation, I was curious about that. :-)

etienneb updated this revision to Diff 56942.May 11 2016, 11:20 AM
etienneb edited edge metadata.

re-generating doc

aaron.ballman accepted this revision.May 11 2016, 12:52 PM
aaron.ballman edited edge metadata.

LGTM, thank you for this!

This revision is now accepted and ready to land.May 11 2016, 12:52 PM
etienneb closed this revision.May 11 2016, 9:26 PM