| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
| |
(Lex to AST).
The member variable is always "LangOpts" and the member function is always "getLangOpts".
Reviewed by Chris Lattner
llvm-svn: 152536
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 152494
|
|
|
|
|
|
|
|
| |
track whether the referenced declaration comes from an enclosing
local context. I'm amenable to suggestions about the exact meaning
of this bit.
llvm-svn: 152491
|
|
|
|
|
|
|
|
|
|
|
| |
doesn't understand. We registered
as aborted, but didn't treat such cases as sinks in the ExplodedGraph.
Along the way, add basic support for CXXCatchStmt, expanding the set of code we actually analyze (hopefully correctly).
Fixes: <rdar://problem/10892489>
llvm-svn: 152468
|
|
|
|
| |
llvm-svn: 152439
|
|
|
|
|
|
|
|
|
| |
This renames the -Wformat-non-standard flag to -Wformat-non-iso,
rewords the current warnings a bit (pointing out that a format string
is not supported by ISO C rather than being "non standard"),
and adds a warning about positional arguments.
llvm-svn: 152403
|
|
|
|
| |
llvm-svn: 152350
|
|
|
|
| |
llvm-svn: 152331
|
|
|
|
|
|
|
|
|
|
| |
The final graph contains a single root node, which is a parent of all externally available functions(and 'main'). As well as a list of Parentless/Unreachable functions, which are either truly unreachable or are unreachable due to our analyses imprecision.
The analyzer checkers debug.DumpCallGraph or debug.ViewGraph can be used to look at the produced graph.
Currently, the graph is not very precise, for example, it entirely skips edges resulted from ObjC method calls.
llvm-svn: 152272
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
analysis to make the AST representation testable. They are represented by a
new UserDefinedLiteral AST node, which is a sugared CallExpr. All semantic
properties, including full CodeGen support, are achieved for free by this
representation.
UserDefinedLiterals can never be dependent, so no custom instantiation
behavior is required. They are mangled as if they were direct calls to the
underlying literal operator. This matches g++'s apparent behavior (but not its
actual mangling, which is broken for literal-operator-ids).
User-defined *string* literals are now fully-operational, but the semantic
analysis is quite hacky and needs more work. No other forms of user-defined
literal are created yet, but the AST support for them is present.
This patch committed after midnight because we had already hit the quota for
new kinds of literal yesterday.
llvm-svn: 152211
|
|
|
|
|
|
| |
block in the CFG.
llvm-svn: 152163
|
|
|
|
|
|
| |
locks.
llvm-svn: 151956
|
|
|
|
|
|
| |
noreturn.
llvm-svn: 151944
|
|
|
|
|
|
| |
Needs llvm update.
llvm-svn: 151829
|
|
|
|
|
|
|
|
| |
to make it more widely available.
Depends on llvm commit r151564
llvm-svn: 151566
|
|
|
|
|
|
|
|
|
| |
This adds the -Wformat-non-standard flag (off by default,
enabled by -pedantic), which warns about non-standard
things in format strings (such as the 'q' length modifier,
the 'S' conversion specifier, etc.)
llvm-svn: 151154
|
|
|
|
|
|
| |
lock, and unlock functions
llvm-svn: 150701
|
|
|
|
| |
llvm-svn: 150700
|
|
|
|
|
|
|
|
|
| |
This is in preparation for being able to warn about 'q' and other
non-standard format string features.
It also allows us to print its name correctly.
llvm-svn: 150697
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit makes PrintfSpecifier::fixType() and ScanfSpecifier::fixType()
only fix a conversion specification enough that Clang wouldn't warn about it,
as opposed to always changing it to use the "canonical" conversion specifier.
(PR11975)
This preserves the user's choice of conversion specifier in cases like:
printf("%a", (long double)1);
where we previously suggested "%Lf", we now suggest "%La"
printf("%x", (long)1);
where we previously suggested "%ld", we now suggest "%lx".
llvm-svn: 150578
|
|
|
|
|
|
| |
<rdar://problem/10814120>
llvm-svn: 149907
|
|
|
|
| |
llvm-svn: 149798
|
|
|
|
|
|
|
|
|
|
|
|
| |
* 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
|
|
|
|
|
|
|
| |
'continue' and another block, prefer the lockset from the other block, and
diagnose the 'continue' block as being the end of a loop.
llvm-svn: 149666
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes the case where Clang would output:
error: format specifies type 'wchar_t *' (aka 'wchar_t *')
ArgTypeResult::getRepresentativeTypeName needs to take into account
that wchar_t can be a built-in type (as opposed to in C, where it is a
typedef).
llvm-svn: 149387
|
|
|
|
| |
llvm-svn: 149385
|
|
|
|
|
|
| |
As discussed at http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120130/052200.html
llvm-svn: 149325
|
|
|
|
| |
llvm-svn: 148885
|
|
|
|
|
|
| |
Fixes PR 9466.
llvm-svn: 148859
|
|
|
|
|
|
| |
r148774, r148775, r148776, r148777
llvm-svn: 148780
|
|
|
|
| |
llvm-svn: 148777
|
|
|
|
| |
llvm-svn: 148775
|
|
|
|
|
|
| |
declarations.
llvm-svn: 148599
|
|
|
|
| |
llvm-svn: 148586
|
|
|
|
| |
llvm-svn: 148577
|
|
|
|
|
|
| |
are used with that and the 'a' length modifier.
llvm-svn: 148029
|
|
|
|
|
|
|
| |
Before r148025 we (accidentally) didn't check whether a length modifier is
appropriate for a scanlist, but now we do.
llvm-svn: 148026
|
|
|
|
| |
llvm-svn: 148025
|
|
|
|
|
|
| |
a rvalue, which is a useful step during AST evaluation.
llvm-svn: 147918
|
|
|
|
| |
llvm-svn: 147672
|
|
|
|
| |
llvm-svn: 147670
|
|
|
|
| |
llvm-svn: 147506
|
|
|
|
| |
llvm-svn: 147331
|
|
|
|
|
|
|
| |
It should not be supported in C++11, since that uses the C99 standard
library, in which 'a' is a format specifier.
llvm-svn: 147310
|
|
|
|
|
|
|
|
|
|
| |
block-level expr. Currently CXXConstructExpr is always added as a block-level
expr. This caused two problems for the analyzer (and potentially for the
CFG-based codegen).
1. We have no way to know whether a ctor call is base or complete.
2. We have no way to know the destination object being contructed.
llvm-svn: 147306
|
|
|
|
| |
llvm-svn: 147203
|
|
|
|
|
|
|
|
| |
PseudoObjExprs. It turns out
that the information collected by this method is a super set of the captured variables in BlockDecl.
llvm-svn: 147122
|
|
|
|
|
|
| |
blocks.
llvm-svn: 147116
|
|
|
|
| |
llvm-svn: 147068
|
|
|
|
| |
llvm-svn: 147066
|