[cfe-dev] Static analyzer question on how to tell if a Decl is a particular c++ function, or a particular class

[Li Kan via cfe-dev]

Hi folks,

If this is not the correct mailing list for this question, please let me
know.

I am trying to write a static analyzer for code base of my current job. The
particular static analyzer I am writing involves a particular class of my
company's code base. Let's say it is T. I want to write a checker to ensure
T.ok() is called before T.value() is called.

Static analyzer is perfect for this type of check as it requires path
sensitive checks. When I trying to write the checker, I basically checks
for pre-call and post-call. I want to tell if a CallEvent is T.ok() and
T.value(). Currently what I am doing is:
1. From CallEvent, I cast to CXXMemberCall, and getOriginExpr(), then call
getMethodDecl().
2. From CXXMethodDecl, I first call getThisType(), then call
getAsCXXRecordDecl(), then getQualifiedNameAsString(), and compare with
qualified name of T, to make sure it is member of T.
3. From CXXMethodDecl, I call getNameAsString() to get the method name, and
compare them with "ok" and "value".

It works, but it looks complicated, and involves string comparison, which I
assume is slow. Is there a easier way, blessed by clang static analyzer
official teams, that tell if a MethodDecl, or CXXRecordDecl, is the
function or class I am interested in?

The ideal way is, there is one-time call to lookup the MethodDecl for
T::ok() and T::value(), and CXXRecordDecl for T. Then ever since then, I
just need to compare the pointers.

Another way is, the first time I found it is T, T::ok() or T::value(), I
save the pointer of CXXRecordDecl or MethodDecl, and use the pointers
later. Is this the reliable (assume I use the pointer canonical decl will
not change) and blessed way to do it? If it is, is my steps above the
correct and simplest way to determine it is T::ok or T::value? Is there
some better and more reliable way?

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180214/20a9767b/attachment.html>