addressing review comments

Addressing review comments

• Created a new checker for smart point derference diagnostic
• Moved checking part to this checker
• Kept all the modeling in SmartPtrModeling
• Created a header file for shared API -calls

Moving dereference precondition checks into checkPreCall.

In D81315#2079457, @Szelethus wrote:

Best of luck on your GSoC! I don't have much else to add to your patch, but you seem to have made good progress already!

Thanks!

In D81315#2078043, @xazax.hun wrote:

some folks have automated scripts based on that tag to add themselves as subscriber/reviewer.

Hope you don't mind my intrusion :)

Not at all.

I am not sure about whether I should use eval::Call or both check::PreCall and check::PostCall. In the eval::Call documentation I found this "Note, that only one checker can evaluate a call.". So I am little bit confused about using it.

Inlining (when we model a function call, https://youtu.be/yh2qdnJjizE?t=238) is rather expensive. Creating a new stack frame, parameters, new ExplodedNodes, running checkers, etc., eats memory for breakfast, is slow and limits how deep the analysis can go. Worse still, the analysis could lose precision if the called function's definition isn't available. eval::Call serves to circumvent this by allowing the analyzer to give a precise summary of the function. StreamChecker, for instance, uses this for functions such as clearerr() -- the C standard defines how this function should behave, so upon encountering a call to it, we don't need all the extra work regular inlining demands, just ask StreamChecker to model it for us.

Use eval::Call if you can provide a precise model for a function. Only a single checker is allowed to do that -- you can see that it returns with a boolean value to sign whether the checker could provide an evaluation, and as far as I know, the first checker that returns true will be doing it.

I think it would be appropriate in this instance, because we're modeling a well established API. In general, I think we should use it when appropriate more often, like in MallocChecker.

Thank you for the detailed help.

Addressing review comments

In D82256#2113233, @NoQ wrote:

@vrnithinkumar what's your preferred Full Name <email> for llvm's git?

clang-format fix

Fixing test failures

Addressing review comment adding miised new line

Fixing wrongly deleted the old commit via arc

Addressing the review comments

It was a mistake
I was supposed to update an existing review.
first time use of arc

fixed the clang-tidy warnig