[PATCH] D142354: [analyzer] Create a stub for an std::variant checker

Artem Dergachev via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Wed Jan 25 19:32:56 PST 2023


NoQ added a comment.

In D142354#4079643 <https://reviews.llvm.org/D142354#4079643>, @Szelethus wrote:

>> In the latter case, have you explored the possibility of force-inlining the class instead, like I suggested in the thread?
>
> I have done some tests then, and figured that the analyzer can't really follow what happens in std::variant. I admit, now that I've taken a more thorough look, I was wrong! Here are some examples.
>
>   std::variant<int, std::string> v = 0;
>   int i = std::get<int>(v);
>   clang_analyzer_eval(i == 0); // expected-warning{{TRUE}}
>   10 / i; // FIXME: This should warn for division by zero!
>
>
>
>   std::variant<int, std::string> v = 0;
>   std::string *sptr = std::get_if<std::string>(&v);
>   clang_analyzer_eval(sptr == nullptr); // expected-warning{{TRUE}}
>   *sptr = "Alma!"; // FIXME: Should warn, sptr is a null pointer!
>
>
>
>   void g(std::variant<int, std::string> v) {
>     if (!std::get_if<std::string>(&v))
>       return;
>     int *iptr = std::get_if<int>(&v);
>     clang_analyzer_eval(iptr == nullptr); // expected-warning{{TRUE}}
>     *iptr = 5; // FIXME: Should warn, iptr is a null pointer!
>   }
>
> In neither of these cases was a warning emitted, but that was a result of bug report suppression, because the exploded graph indicates that the errors were found.
>
> We will need to teach these suppression strategies in these cases, the heuristic is too conservative, and I wouldn't mind some `NoteTag`s to tell the user something along the lines of "Assuming this variant holds and std::string value".

Yeah, right, these are probably inlined defensive check suppressions (type-2, the ones with "let's early-return null"). So you'll need to see how these inlined stack frames look like and what makes them different from the unwanted case. (And it's possible that there are no formal differences, other than the programmer's "intention"; but it could also be something really simple).

So in any case, I'm really curious whether there's any solution besides "let's model everything manually", given that we've spent two summers modeling `unique_ptr` manually and never finished it.


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

https://reviews.llvm.org/D142354



More information about the cfe-commits mailing list