Page MenuHomePhabricator

[analyzer][CallAndMessage][NFC] Split up checkPreCall

Authored by Szelethus on Apr 9 2020, 6:25 PM.



The patch aims to use CallEvents interface in a more principled manner, and also to highlight what this checker really does. It in fact checks for 5 different kinds of errors (from checkPreCall, that is):

  • Invalid function pointer related errors
  • Call of methods from an invalid C++ this object
  • Function calls with incorrect amount of parameters
  • Invalid arguments for operator delete
  • Pass of uninitialized values to pass-by-value parameters

In a previous patch I complained that this checker is responsible for emitting a lot of different diagnostics all under core.CallAndMessage's name, and this patch shows where we could start to assign different diagnostics to different entities.

Diff Detail

Event Timeline

Szelethus created this revision.Apr 9 2020, 6:25 PM
balazske added inline comments.May 8 2020, 2:53 AM

The one thing where I am not sure is if this condition is really needed for every case (for example can checkFunctionPointerCall be moved outside this if?). I see only that checkParameterCount has to be in this if block.

balazske added inline comments.May 8 2020, 3:01 AM

Are these new includes needed?

Szelethus updated this revision to Diff 265214.May 20 2020, 5:34 AM
Szelethus marked 4 inline comments as done.

Fixes according to @balazske's comments, cheers!

Szelethus added inline comments.May 20 2020, 5:38 AM

Nope, you're right.


@balazske this is the corresponding condition that got changed. Now, your inline is fair, and I remember being puzzled by needing that condition to not crash. One thing to note is that CallAndMessage really tests every part of CallEvent, and since its registered very early (its also a dependency in addition to being a core checker) it runs before most other checkers. Anyways, I revisited each of the new functions I added, and wow, you totally nailed it. Nothing crashes if I remove that condition, but I vividly remember it breaking earlier.

So yeah, nice catch!

balazske accepted this revision.May 21 2020, 2:21 AM

Looks good. Not sure if it work in all cases after the MallocChecker problems but we can fix problems if any later.

This revision is now accepted and ready to land.May 21 2020, 2:21 AM
This revision was automatically updated to reflect the committed changes.