forked from OSchip/llvm-project
9d3ca9a5ae
Using ARC, strong, weak, and autoreleasing stack variables are implicitly
initialized with nil. This includes variable-length arrays of Objective-C object
pointers. However, in the analyzer we don't zero-initialize them. We used to,
but it accidentally regressed after r289618.
Under ARC, the array variable's initializer within DeclStmt is an
ImplicitValueInitExpr. Environment doesn't maintain any bindings for this
expression kind - instead it always knows that it's a known constant
(0 in our case), so it just returns the known value by calling
SValBuilder::makeZeroVal() (see EnvironmentManager::getSVal().
Commit r289618 had introduced reasonable behavior of SValBuilder::makeZeroVal()
for the arrays, which produces a zero-length compoundVal{}. When such value
is bound to arrays, in RegionStoreManager::bindArray() "remaining" items in the
array are default-initialized with zero, as in
RegionStoreManager::setImplicitDefaultValue(). The similar mechanism works when
an array is initialized by an initializer list that is too short, eg.
int a[3] = { 1, 2 };
would result in a[2] initialized with 0. However, in case of variable-length
arrays it didn't know if any more items need to be added,
because, well, the length is variable.
Add the default binding anyway, regardless of how many actually need
to be added. We don't really care how many, because the default binding covers
the whole array anyway.
Differential Revision: https://reviews.llvm.org/D41478
rdar://problem/35477763
llvm-svn: 321290
|
||
|---|---|---|
| .. | ||
| ARCMigrate | ||
| AST | ||
| ASTMatchers | ||
| Analysis | ||
| Basic | ||
| CodeGen | ||
| CrossTU | ||
| Driver | ||
| Edit | ||
| Format | ||
| Frontend | ||
| FrontendTool | ||
| Headers | ||
| Index | ||
| Lex | ||
| Parse | ||
| Rewrite | ||
| Sema | ||
| Serialization | ||
| StaticAnalyzer | ||
| Tooling | ||
| CMakeLists.txt | ||