NagyDonat wrote: > Only evalCall what we need, and exactly that. This means only 2 APIs: > `std::sort` and `std::stable_sort`. It's easy to model these accurately > because the best a proper model could do is just escaping the parameters.
There is also `std::inplace_merge` but what you write is also true for that function. I think this clearly answers the concern when @gamesh411 asked that > I think the same could be said about the "public API" of the sort functions > the std::sort and co. If we evalCall those, we cannot model them elsewhere, > so that leaves us with suppressing the problematic internals. ----- > With any other APIs, the modelling is likely to be not that simple and can > cause negative interference like you observed - with other checkers. > Consequently, I'd steer away from those and focus on the bare minimums. I agree that this commit should be limited to finding a good solution for the three function `std::sort`, `std::stable_sort` and `std::inplace_merge`. I also understand and like that @gamesh411 wanted to "think ahead" and check whether his solution is sufficient for also covering the other suppressions. It is a bit unfortunate that this modeling checker won't be able to cover those other function (because it would clash with the other EvalCall checkers), but that's acceptable. If there are some visitor-based suppressions that can be easily ported to this checker, then do so _in a follow-up commit_, but if there are difficulties, then don't bother with it. (The current suppression-based approach also works, there is no urgent need to replace it.) ------- On a long term it would be nice to assign priorities to evalCall checkers to allow situations where two checkers would evaluate the same call -- and the one with the higher priority "wins". With this feature it would be straightforward to implement `OpaqueSTLFunctionsModeling` as a low-priority evalCall callback that activates if nothing else evaluates the call. I don't think that replacing the visitor-based suppressions is important enough to justify this change in the behavior of `evalCall` checkers, but I already thought about introducing priorities earlier (perhaps a year ago, for some other unrelated goal) and if we eventually introduce them, then this will become a low-hanging fruit. https://github.com/llvm/llvm-project/pull/178910 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
