instantiation), be sure to add the transformed declaration into the
current DeclContext. Also, remove the -Wuninitialized hack that works
around this bug. Fixes <rdar://problem/9200676>.
llvm-svn: 129544
evaluated and unevaluated contexts. Add some testing of sizeof and
typeid.
Both of the typeid tests added here were triggering warnings previously.
Now the one false positive is suppressed without suppressing the warning
on actually buggy code.
llvm-svn: 129431
marked explicitly as uninitialized through direct self initialization:
int x = x;
With r128894 we prevented warnings about this code, and this patch
teaches the analysis engine to continue analyzing subsequent uses of
'x'. This should wrap up PR9624.
There is still an open question of whether we should suppress the
maybe-uninitialized warnings resulting from variables initialized in
this fashion. The definitely-uninitialized uses should always be warned.
llvm-svn: 128932
1) Change the CFG to include the DeclStmt for conditional variables, instead of using the condition itself as a faux DeclStmt.
2) Update ExprEngine (the static analyzer) to understand (1), so not to regress.
3) Update UninitializedValues.cpp to initialize all tracked variables to Uninitialized at the start of the function/method.
4) Only use the SelfReferenceChecker (SemaDecl.cpp) on global variables, leaving the dataflow analysis to handle other cases.
The combination of (1) and (3) allows the dataflow-based -Wuninitialized to find self-init problems when the initializer
contained control-flow.
llvm-svn: 128858
Note this can potentially be enhanced to detect if the __block variable
is actually written by the block, or only when the block "escapes" or
is actually used, but that requires more analysis than it is probably worth
for this simple check.
llvm-svn: 128681
my expertise on the template instantiation logic isn't good enough to fix this problem for real. This patch worksaround the
problem in -Wuninitialized, but we should fix it for real later.
llvm-svn: 128443
This rename serves two purposes:
- It reflects the actual functionality of this analysis.
- We will have more than one reachability analysis.
llvm-svn: 127930
Change the interface to expose the new information and deal with the enormous fallout.
Introduce the new ExceptionSpecificationType value EST_DynamicNone to more easily deal with empty throw specifications.
Update the tests for noexcept and fix the various bugs uncovered, such as lack of tentative parsing support.
llvm-svn: 127537
Instead, create a small set of Stmt* -> CFGBlock* mappings during CFG construction for only the statements we care about
relating to the diagnostics we want to check for reachability.
llvm-svn: 127396
Moreover, change AnalysisContext to use an OwningPtr for created analysis objects instead
of directly managing them.
Finally, add a 'forcedBlkExprs' entry to CFG::BuildOptions that will be used by the
CFGBuilder to force specific expressions to be block-level expressions.
llvm-svn: 127385
conventional categories into Basic and AST. Update the self-init checker
to use this logic; CFRefCountChecker is complicated enough that I didn't
want to touch it.
llvm-svn: 126817
This fixes a crash reported in PR9287, and also fixes a false positive involving the value of such ternary
expressions not properly getting propagated.
llvm-svn: 126362
Ted Kremenek