cases in switch statements. Also add a [[clang::fallthrough]] attribute, which
can be used to suppress the warning in the case of intentional fallthrough.
Patch by Alexander Kornienko!
The handling of C++11 attribute namespaces in this patch is temporary, and will
be replaced with a cleaner mechanism in a subsequent patch.
llvm-svn: 156086
#define TEST int y; int x = y;
void foo() {
TEST
}
-Wuninitialized gives this warning:
invalid-loc.cc:4:3: warning: variable 'y' is uninitialized when used here
[-Wuninitialized]
TEST
^~~~
invalid-loc.cc:2:29: note: expanded from macro 'TEST'
#define TEST int y; int x = y;
^
note: initialize the variable 'y' to silence this warning
1 warning generated.
The second note lacks filename, line number, and code snippet. This change
will remove the fixit and only point to variable declaration.
invalid-loc.cc:4:3: warning: variable 'y' is uninitialized when used here
[-Wuninitialized]
TEST
^~~~
invalid-loc.cc:2:29: note: expanded from macro 'TEST'
#define TEST int y; int x = y;
^
invalid-loc.cc:4:3: note: variable 'y' is declared here
TEST
^
invalid-loc.cc:2:14: note: expanded from macro 'TEST'
#define TEST int y; int x = y;
^
1 warning generated.
llvm-svn: 156045
std::list is expensive, but so is std::sorting a SmallVector of SmallVectors of
heavyweight PartialDiagnostics.
Saves ~30k in a i386-linux-Release+Asserts clang build.
llvm-svn: 153437
function, provide a specialized diagnostic that indicates the kind of
special member function (default constructor, copy assignment
operator, etc.) and that it was implicitly deleted. Add a hook where
we can provide more detailed information later.
llvm-svn: 150611
This seems to negatively affect compile time onsome ObjC tests
(which use a lot of partial diagnostics I assume). I have to come
up with a way to keep them inline without including Diagnostic.h
everywhere. Now adding a new diagnostic requires a full rebuild
of e.g. the static analyzer which doesn't even use those diagnostics.
This reverts commit 6496bd10dc3a6d5e3266348f08b6e35f8184bc99.
This reverts commit 7af19b817ba964ac560b50c1ed6183235f699789.
This reverts commit fdd15602a42bbe26185978ef1e17019f6d969aa7.
This reverts commit 00bd44d5677783527d7517c1ffe45e4d75a0f56f.
This reverts commit ef9b60ffed980864a8db26ad30344be429e58ff5.
llvm-svn: 150006
Fix all the files that depended on transitive includes of Diagnostic.h.
With this patch in place changing a diagnostic no longer requires a full rebuild of the StaticAnalyzer.
llvm-svn: 149781
* When we detect that a CFG block has inconsistent lock sets, point the
diagnostic at the location where we found the inconsistency, and point a note
at somewhere the inconsistently-locked mutex was locked.
* Fix the wording of the normal (non-loop, non-end-of-function) case of this
diagnostic to not suggest that the mutex is going out of scope.
* Fix the diagnostic emission code to keep a warning and its note together when
sorting the diagnostics into source location order.
llvm-svn: 149669
- If the declarator is at the start of a line, and the previous line contained
another declarator and ended with a comma, then that comma was probably a
typo for a semicolon:
int n = 0, m = 1, l = 2, // k = 5;
myImportantFunctionCall(); // oops!
- If removing the parentheses would correctly initialize the object, then
produce a note suggesting that fix.
- Otherwise, if there is a simple initializer we can suggest which performs
value-initialization, then provide a note suggesting a correction to that
initializer.
Sema::Declarator now tracks the location of the comma prior to the declarator in
the declaration, if there is one, to facilitate providing the note. The code to
determine an appropriate initializer from the -Wuninitialized warning has been
factored out to allow use in both that and -Wvexing-parse.
llvm-svn: 148072
explicit template specializations (which represent actual functions somebody wrote).
Along the way, refactor some other code which similarly cares about whether or
not they are looking at a template instantiation.
llvm-svn: 145547
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
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
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
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
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
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
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
This rename serves two purposes:
- It reflects the actual functionality of this analysis.
- We will have more than one reachability analysis.
llvm-svn: 127930
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
diagnostics that occur in unreachable code (e.g., -Warray-bound).
We only pay the cost of doing the reachability analysis when we issue one of these diagnostics.
llvm-svn: 126290
Implicit dtors confuse the ad hoc path-sensitivity of UninitializedValuesV2.cpp. This isn't
the ideal solution, as it will directly impact compile time, but should significantly reduce
the noise of -Wuninitialized on some code bases.
This immediately "fixes" the false positive reported in PR 9063, although this
isn't the right fix in the long run.
llvm-svn: 124667
after a 'return' in a CFGBlock. This accidentally
was working before, but the false assumption that
'return' always appeared at the end of the block
was uncovered by a recent change.
llvm-svn: 124280
handling all CFGElement kinds. While writing
the test case, it turned out that return-noreturn.cpp
wasn't actually testing anything since it has the wrong -W
flag. That uncovered another regression with
the handling of destructors marked noreturn. WIP.
llvm-svn: 124238
to issue the warning at an uninitialized variable's
declaration, but to issue notes at possible
uninitialized uses (which could be multiple).
llvm-svn: 123994
references by monitoring whether an access to
a variable is solely to compute it's lvalue or
to do an lvalue-to-rvalue conversion (i.e., a load).
llvm-svn: 123777
temporaries with no-return destructors. The CFG now properly supports
temporaries and implicit destructors which both makes this kludge no
longer work, and conveniently removes the need for it.
Turn on CFG handling of implicit destructors and initializers. Several
ad-hoc benchmarks don't indicate any measurable performance impact from
growing the CFG, and it fixes real correctness problems with warnings.
As a result of turning on these CFG elements, we started to tickle an
inf-loop in the unreachable code logic used for warnings. The fix is
trivial.
llvm-svn: 123056
Diagnostic pragmas are broken because we don't keep track of the diagnostic state changes and we only check the current/latest state.
Problems manifest if a diagnostic is emitted for a source line that has different diagnostic state than the current state; this can affect
a lot of places, like C++ inline methods, template instantiations, the lexer, etc.
Fix the issue by having the Diagnostic object keep track of the source location of the pragmas so that it is able to know what is the diagnostic state at any given source location.
Fixes rdar://8365684.
llvm-svn: 121873
Richard Smith