It models the LLVM casts:
- cast<>
- dyn_cast<>
- cast_or_null<>
- dyn_cast_or_null<>
It has a very basic support without checking the classof() function.
Differential D64374
[analyzer] CastValueChecker: Model casts Charusso on Jul 8 2019, 3:39 PM. Authored by
Details
It models the LLVM casts:
It has a very basic support without checking the classof() function.
Diff Detail Event Timeline
Comment Actions Thanks! My mind was really set to actually model these with classof(), whoops.
Comment Actions We should add at least some tests for the other three functions.
Comment Actions
Comment Actions Whoops. I underestimated you (: Ok, anyway, this was my last comment. Great job! Remember to make sure that it works on the actual LLVM, not only on tests; mocked-up test headers are very easy to get wrong. Comment Actions The only crash-able code was that: #0 Calling llvm::unique_dyn_cast where: ProgramStateRef ExprEngine::createTemporaryRegionIfNeeded(): Assertion `!InitValWithAdjustments.getAs<Loc>() || Loc::isLocType(Result->getType()) || Result->getType()->isMemberPointerType()' because of cast<>: template <class X, class Y> LLVM_NODISCARD inline auto unique_dyn_cast(std::unique_ptr<Y> &Val) -> decltype(cast<X>(Val)) { if (!isa<X>(Val)) return nullptr; return cast<X>(std::move(Val)); } (source: https://llvm.org/doxygen/Casting_8h_source.html) So we bypass every error with that CXXRecordDecl checking from now. Would we like to model that? Comment Actions Well, unique_dyn_cast<> and unique_dyn_cast_or_null<> is used like 20 times in the LLVM codebase, whoops. We want to model it. Full info: Edit: removed due it breaks the entire page. Comment Actions Mmm. Ok, am i understanding correctly that this was crashing because you bound a 0 (Loc) to a prvalue expression of type unique_ptr? Yeah, right, don't do that :)
That doesn't sound like it's high on our list. That's not too many times. Probably very few false positives come out of it. Also modeling smart pointers is much harder than modeling regular pointers. We could add some modeling into SmartPtrChecker, but that'd require actually developing that checker :) Comment Actions Thanks for the review! Hm, because it is smart, probably it is out of our scope. Thanks for pointing it out! Comment Actions I guess getAs and castAs methods could join the party too. I'm evaluating plenty of results on LLVM, and those seem to be in the same problem category. Comment Actions Do you have plans to extend this checker with the modeling of isa<>? I might take that off your shoulder if not :) Comment Actions Hey! Sorry for the late response, just it is a heavy change. This patch creates about 200 TP, I have checked out every of the new reports. |
I believe we want to put this checker as well as the return value checker into apiModeling.llvm.
This doesn't prevent the checkers from being generally useful for other packages: if we want to add support for other APIs, we'll simply reserve a different checker name for the same checker object (with internal flags to enable/disable particular API groups).