llvm-svn: 139723

Thread safety: Initializing var before exhaustive switch statement to deal with extraneous warning produced by gcc but not clang

llvm-svn: 139611

This deletes a bunch of crufty code, and allows more logic sharing
between the analyzer and the warnings.

llvm-svn: 139594

llvm-svn: 139463

methods, and improve the diagnostic slightly along the way. Fixes
<rdar://problem/10098695>.

llvm-svn: 139446

Thread safety: This patch deals with previously unhandled cases when building lock expressions. We now resolve this expressions, avoid crashing when encountering cast expressions, and have a diagnostic for unresolved lock expressions

llvm-svn: 139370

llvm-svn: 139369

llvm-svn: 139368

llvm-svn: 139367

llvm-svn: 139331

Thread Safety:  In C++0x Mutexes are the objects that control access to shared variables, while Locks are the objects that acquire and release Mutexes. We switch to this new terminology.

llvm-svn: 139321

llvm-svn: 139310

llvm-svn: 139308

llvm-svn: 139307

class scope.

This patch was also written by DeLesley Hutchins.

llvm-svn: 139301

of the function in question when applicable (that is, not for blocks).
Patch by Joerg Sonnenberger with some stylistic tweaks by me.

When discussing this weth Joerg, streaming the decl directly into the
diagnostic didn't work because we have a pointer-to-const, and the
overload doesn't accept such. In order to make my style tweaks to the
patch, I first changed the overload to accept a pointer-to-const, and
then changed the diagnostic printing layer to also use
a pointer-to-const, cleaning up a gross line of code along the way.

llvm-svn: 138854

Thread safety: added basic handling for pt_guarded_by/var and guarded_by/var annotations. We identify situations where we are accessing (reading or writing) guarded variables, and report an error if the appropriate locks are not held.

llvm-svn: 138774

This patch is by DeLesley Hutchins.

llvm-svn: 138738

pointer variable. Patch by David Blaikie!

llvm-svn: 138687

Thread safety: Fix a few typos in last commit -- use LockID instead of Lock in comments and start a couple methods with a lowercase letter

llvm-svn: 138460

handled SCC's of dead code, or simply having false negatives by overly suppressing warnings.

WIP.

llvm-svn: 138410

llvm-svn: 138408

system flags an error when unlocking a lock which was not held, locking
the same lock twice, having a different lockset on each iteration of a
loop, or going out of scope while still holding a lock. In order to
successfully use the lockset, this patch also makes sure that attribute
arguments are attached correctly for later parsing.

This patch was also worked on by DeLesley Hutchins.

Note: This patch has been reviewed by Chandler Carruth and Jeffrey
Yasskin. Feel free to provide post-commit review comments for a
subsequent patch.

llvm-svn: 138350

them into the clang namespace.

llvm-svn: 135852

AnalysisBasedWarnings Sema layer and out of the Analysis library itself.
This returns the uninitialized values analysis to a more pure form,
allowing its original logic to correctly detect some categories of
definitely uninitialized values. Fixes PR10358 (again).

Thanks to Ted for reviewing and updating this patch after his rewrite of
several portions of this analysis.

llvm-svn: 135748

llvm-svn: 135666

This is accomplished by forcing the needed expressions for -Wuninitialized to always be CFGElements in the CFG.
This allows us to remove a fair amount of the code for -Wuninitialized.

Some fallout:
- AnalysisBasedWarnings.cpp now specifically toggles the CFGBuilder to create a CFG that is suitable for -Wuninitialized.  This
is a layering violation, since the logic for -Wuninitialized is in libAnalysis.  This can be fixed with the proper refactoring.
- Some of the source locations for -Wunreachable-code warnings have shifted.  While not ideal, this is okay because that analysis
already needs some serious reworking.

llvm-svn: 135480

Zero this struct in a way that neither depends on the size of the struct nor triggers warnings from GCC.

llvm-svn: 135351

llvm-svn: 135348

Found by valgrind.

llvm-svn: 134733

rather than a computed std::distance(). At some point I had convinced
myself that these two were different; but as far as I can tell on
re-exampination they aren't, and the number of block IDs is actually
just a count of the blocks in the CFG.

While this removes the primary motivation for guarding all of this with
CollectStats, I have a patch coming up that will almost certainly make
it important again.

llvm-svn: 134552

Special detail is added for uninitialized variable analysis as this has
serious performance problems than need to be tracked.

Computing some of this data is expensive, for example walking the CFG to
determine its size. To avoid doing that unless the stats data is going
to be used, we thread a bit into the Sema object to track whether
detailed stats should be collected or not. This bit is used to avoid
computations whereever the computations are likely to be more expensive
than checking the state of the flag. Thus, counters are in some cases
unconditionally updated, but the more expensive (and less frequent)
aggregation steps are skipped.

With this patch, we're able to see that for 'gcc.c':
*** Analysis Based Warnings Stats:
232 functions analyzed (0 w/o CFGs).
  7151 CFG blocks built.
  30 average CFG blocks per function.
  1167 max CFG blocks per function.
163 functions analyzed for uninitialiazed variables
  640 variables analyzed.
  3 average variables per function.
  94 max variables per function.
  96409 block visits.
  591 average block visits per function.
  61546 max block visits per function.

And for the reduced testcase in PR10183:
*** Analysis Based Warnings Stats:
98 functions analyzed (0 w/o CFGs).
  8526 CFG blocks built.
  87 average CFG blocks per function.
  7277 max CFG blocks per function.
68 functions analyzed for uninitialiazed variables
  1359 variables analyzed.
  19 average variables per function.
  1196 max variables per function.
  2540494 block visits.
  37360 average block visits per function.
  2536495 max block visits per function.

That last number is the somewhat scary one that indicates the problem in
PR10183.

llvm-svn: 134494

over "= 0". Fixes <rdar://problem/9714386>.

llvm-svn: 134302

then teach -Wreturn-type to handle the same.  Net effect:  we now correctly
handle noreturn attributes on member calls in the CFG.

llvm-svn: 131178

function more clear and obvious in behavior.

Add some comments documenting the behavior of the primary diagnostic helper.

llvm-svn: 128901

diagnostic emission. The fixit hint, when suggested, typically has
nothing to do with the nature or form of the reference.

llvm-svn: 128899

extracts a function to handle the emission of the diagnostic separately
from the walking over the set of uninitialized uses.

Also updates the naming used within this extracted function to be a bit
more consistent with the rest of Clang's naming patterns.

The next step will be breaking this apart so that we can go through
different functions rather than tracking so many boolean variables.

llvm-svn: 128898

  int x = x;

GCC disables its warnings on this construct as a way of indicating that
the programmer intentionally wants the variable to be uninitialized.
Only the warning on the initializer is turned off in this iteration.

This makes the code a lot more ugly, but starts commenting the
surprising behavior here. This is a WIP, I want to refactor it
substantially for clarity, and to determine whether subsequent warnings
should be suppressed or not.

llvm-svn: 128894

I think this moves the code in the desired direction of the new style
recommendations (and style conventional in Clang), but if anyone prefers
the previous style, or has other suggestions just chime in and I'll
follow up.

llvm-svn: 128878

Fix PR 9626 (duplicated self-init warnings under -Wuninitialized) with numerous CFG and UninitializedValues analysis changes:

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