summaryrefslogtreecommitdiff
path: root/clang/test/Analysis/template-param-objects.cpp
AgeCommit message (Collapse)Author
2025-11-04[analyzer] Revert incorrect LazyCoumpoundVal changes (#163461)Marco Borgeaud
Reverts #115917 and its follow up #116840. Fixes #153782 and introduces regression tests. Reopens #114270.
2024-11-29[analyzer] Avoid creating LazyCompoundVal when possible (#116840)Balazs Benics
In #115916 I allowed copying empty structs. Later in #115917 I changed how objects are copied, and basically when we would want to copy a struct (an LCV) of a single symbol (likely coming from an opaque fncall or invalidation), just directly bind that symbol instead of creating an LCV referring to the symbol. This was an optimization to skip a layer of indirection. Now, it turns out I should have apply the same logic in #115916. I should not have just blindly created an LCV by calling `createLazyBinding()`, but rather check if I can apply the shortcut described in #115917 and only create the LCV if the shortcut doesn't apply. In this patch I check if there is a single default binding that the copy would refer to and if so, just return that symbol instead of creating an LCV. There shouldn't be any observable changes besides that we should have fewer LCVs. This change may surface bugs in checkers that were associating some metadata with entities in a wrong way. Notably, STLAlgorithmModeling and DebugIteratorModeling checkers would likely stop working after this change. I didn't investigate them deeply because they were broken even prior to this patch. Let me know if I should migrate these checkers to be just as bugged as they were prior to this patch - thus make the tests pass.
2022-10-13[analyzer] Workaround crash on encountering Class non-type template parametersBalazs Benics
The Clang Static Analyzer will crash on this code: ```lang=C++ struct Box { int value; }; template <Box V> int get() { return V.value; } template int get<Box{-1}>(); ``` https://godbolt.org/z/5Yb1sMMMb The problem is that we don't account for encountering `TemplateParamObjectDecl`s within the `DeclRefExpr` handler in the `ExprEngine`. IMO we should create a new memregion for representing such template param objects, to model their language semantics. Such as: - it should have global static storage - for two identical values, their addresses should be identical as well http://eel.is/c%2B%2Bdraft/temp.param#8 I was thinking of introducing a `TemplateParamObjectRegion` under `DeclRegion` for this purpose. It could have `TemplateParamObjectDecl` as a field. The `TemplateParamObjectDecl::getValue()` returns `APValue`, which might represent multiple levels of structures, unions and other goodies - making the transformation from `APValue` to `SVal` a bit complicated. That being said, for now, I think having `Unknowns` for such cases is definitely an improvement to crashing, hence I'm proposing this patch. Reviewed By: xazax.hun Differential Revision: https://reviews.llvm.org/D135763