[PATCH] D77658: [analyzer] StdLibraryFunctionsChecker: Add sanity checks for constraints

Balázs Kéri via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Fri May 29 03:13:31 PDT 2020


balazske added a comment.

The code looks basically good to me, some documentations can be improved.



================
Comment at: clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp:697
         if (auto *FD = dyn_cast<FunctionDecl>(D)) {
-          if (S.matchesSignature(FD)) {
+          if (S.Sign.matches(FD) && S.validate(FD)) {
             auto Res = Map.insert({FD->getCanonicalDecl(), S});
----------------
martong wrote:
> balazske wrote:
> > martong wrote:
> > > Szelethus wrote:
> > > > This looks a bit odd, we're checking whether the function matches, and than we validate right after? Shouldn't we just not match the `FD` if it isn't valid?
> > > Yeah, ok, I moved the validation back into `matchesSignature`.
> > I think these are not related, there should be signature match and validness check, but it is natural to check first the signature, then the validness.
> @Szelethus, @balazske : I agree with both of you so I renamed `matchesSignature` to `matches`, which is a shorthand to the the signature match and then the validity check (and added a comment):
> ```
>     // Returns true if the summary should be applied to the given function.
>     bool matches(const FunctionDecl *FD) const {
>       return Sign.matches(FD) && validateByConstraints(FD);
>     }
> ```
Suggestion: Maybe we can have one function for `matches` and `setFunctionDecl` (set it if matches). We do not want to change the function decl later anyway, and not to something that does not match.


================
Comment at: clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp:68
   /// We avoid nesting types here because each additional qualifier
   /// would need to be repeated in every function spec.
+  class Summary;
----------------
This text above is not the documentation of `Summary` (is it attached to `Summary` by doxygen?). Probably not `///` is needed, only `//`. And it is probably out of date now, at least I can not understand immediately what is it about (what typedef's are these, what kind of "nesting types"). 


================
Comment at: clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp:116
+
+    /// Do sanity check on the constraint.
+    bool checkValidity(const FunctionDecl *FD) const {
----------------
We check here that a function is a suitable candidate to be used with the constraint? (We select a function for the constraint, not a constraint for a function.) Maybe a better description would help to clarify this.


================
Comment at: clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp:571
   // Apply case/branch specifications.
-  for (const auto &VRS : Summary.CaseConstraints) {
+  for (const auto &VRS : Summary.getCaseConstraints()) {
     ProgramStateRef NewState = State;
----------------
It may be better to see type of `VRS` instead of `auto` (and know what the `VRS` abbrevation means, why not `CC` for case constraint and not `VC` for `ValueConstraint`). Same for `VR` below.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77658/new/

https://reviews.llvm.org/D77658





More information about the cfe-commits mailing list