| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
llvm-svn: 210615
|
| |
|
|
|
|
|
|
|
|
| |
use out of TransferFunctions, and compute it in advance rather than on-the-fly.
This allows us to handle compound assignments with DeclRefExprs on the RHS
correctly, and also makes it trivial to treat const& function parameters as not
initializing the argument. The patch also makes both of those changes.
llvm-svn: 160330
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
diagnostic message are compared. If either is a substring of the other, then
no error is given. This gives rise to an unexpected case:
// expect-error{{candidate function has different number of parameters}}
will match the following error messages from Clang:
candidate function has different number of parameters (expected 1 but has 2)
candidate function has different number of parameters
It will also match these other error messages:
candidate function
function has different number of parameters
number of parameters
This patch will change so that the verification string must be a substring of
the diagnostic message before accepting. Also, all the failing tests from this
change have been corrected. Some stats from this cleanup:
87 - removed extra spaces around verification strings
70 - wording updates to diagnostics
40 - extra leading or trailing characters (typos, unmatched parens or quotes)
35 - diagnostic level was included (error:, warning:, or note:)
18 - flag name put in the warning (-Wprotocol)
llvm-svn: 146619
|
| |
|
|
|
|
| |
warnings.
llvm-svn: 139463
|
| |
|
|
|
|
| |
resulting from the recent -Wuninitialized changes.
llvm-svn: 137068
|
| |
|
|
| |
llvm-svn: 136939
|
| |
|
|
|
|
| |
passed by reference.
llvm-svn: 135610
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
definitely have a path leading to them, and possibly have a path leading
to them; reflect that distinction in the warning text emitted.
llvm-svn: 129126
|
| |
|
|
|
|
| |
statements.
llvm-svn: 129102
|
| |
|
|
| |
llvm-svn: 128840
|
| |
|
|
|
|
|
|
|
| |
to an assertion failure in the uninitialized variables analysis. The problem is that Sema isn't properly registering a variable in a DeclContext (which -Wuninitialized relies on), but
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
|
| |
|
|
|
|
| |
*must-be-uninitialized* warnings are reported, with *maybe-uninitialized* under a separate flag. I await any fallout/comments/feedback, although hopefully this will produce no noise for users.
llvm-svn: 127670
|
| |
|
|
|
|
| |
-Wuninitialized-experimental. It is clear from user feedback that this warning is not quite ready.
llvm-svn: 125007
|
| |
|
|
| |
llvm-svn: 124924
|
| |
|
|
|
|
| |
refer to the bad use, and the note to the variable declaration.
llvm-svn: 124758
|
| |
|
|
| |
llvm-svn: 124279
|
| |
|
|
|
|
|
| |
for floats, and also check if 'nil' is declared
when suggesting it for initializing ObjC pointers.
llvm-svn: 124004
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
| |
handling pseudo-path sensitivity, and instead
use those assertion conditions as dynamic checks.
These assertions would be violated when analyzing
a CFG where some branches where optimized away
during CFG construction because their branch
conditions could be trivially determined.
llvm-svn: 123943
|
|
|
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
|
