| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
| |
doesn't get called for each CallExpr. Instead it does a switch and only runs the check for the proper identifier. Slight speed improvement (probably significant on very large ASTs), and should make it easier and more clear to add more checks for other CallExpr's later.
llvm-svn: 128785
|
| |
|
|
|
|
|
|
| |
position of a branch condition, and a new generateNode method to BranchNodeBuilder using PostCondition ProgramPoint. This method generates a new ExplodedNode but not a new block edge.
Patch by Lei Zhang!
llvm-svn: 128784
|
| |
|
|
|
|
| |
assigned a LazyCompoundValue. Fixes <rdar://problem/9163742> and PR 9522.
llvm-svn: 128783
|
| |
|
|
|
|
| |
non-header file.
llvm-svn: 128780
|
| |
|
|
|
|
| |
CharUnits. No change in functionality intended.
llvm-svn: 128776
|
| |
|
|
|
|
| |
change in functionality intended.
llvm-svn: 128773
|
| |
|
|
|
|
| |
dumpLayout(). No change in functionality intended.
llvm-svn: 128771
|
| |
|
|
|
|
| |
change in functionality intended.
llvm-svn: 128770
|
| |
|
|
|
|
|
|
|
|
|
| |
a couple of operator overloads which form interesting expressions in the
AST.
I added test cases for both bugs with the c-index-test's token
annotation feature. Also, thanks to John McCall for confirming that this
is the correct solution.
llvm-svn: 128768
|
| |
|
|
| |
llvm-svn: 128762
|
| |
|
|
|
|
| |
didn't know how to handle a specific Expr type.
llvm-svn: 128761
|
| |
|
|
|
|
| |
a given CFGBlock was analyzed too many times.
llvm-svn: 128760
|
| |
|
|
|
|
| |
functionality intended.
llvm-svn: 128756
|
| |
|
|
|
|
| |
CharUnits. No change in functionality intended.
llvm-svn: 128754
|
| |
|
|
|
|
| |
functionality intended.
llvm-svn: 128753
|
| |
|
|
|
|
| |
No change in functionality intended.
llvm-svn: 128752
|
| |
|
|
|
|
| |
block pointer nested inside a block. // rdar:// 9204669
llvm-svn: 128747
|
| |
|
|
| |
llvm-svn: 128738
|
| |
|
|
|
|
| |
__byref block. // rdar://9204669
llvm-svn: 128726
|
| |
|
|
| |
llvm-svn: 128725
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
location into a TemplateSpecializationTypeLoc. These were found using
a hand-written program to inspect every source location in
TemplateSpecializationTypeLocs and Valgrind. I don't know of any way to
test them in Clang's existing test suite sadly.
Example code that triggers the ElaboratedType case:
template <typename T> struct X1 {
template <typename U> struct X1_1 {
int x;
};
};
template <typename T, typename U> struct X2 {
typename X1<T>::template X1_1<U> B;
};
X2<char, int> x2;
The other fix was simply spotted by inspection. I audited all constructions of
[Dependent]TemplateSpecializationTypeLocs in TreeTransform.h, and the rest set
the TemplateNameLoc properly.
llvm-svn: 128702
|
| |
|
|
|
|
| |
that of the array element type.
llvm-svn: 128698
|
| |
|
|
|
|
| |
arrays by propagating", it's breaking test in ways I don't understand yet.
llvm-svn: 128693
|
| |
|
|
|
|
|
|
| |
the array alignment to the array access.
- This is more or less the best we can do without having alignment present in
the type system, but is a long way from truly matching how GCC handles this.
llvm-svn: 128691
|
| |
|
|
|
|
| |
__block block declaration. //rdar://9204669
llvm-svn: 128682
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
generate a warning any time the strcpy() function is used with a note suggesting to use a function which provides bounded buffers.
llvm-svn: 128679
|
| |
|
|
|
|
| |
Models mempcpy() so that if length is NULL the destination pointer is returned. Otherwise, the source and destination are confirmed not to be NULL and not overlapping. Finally the copy is validated to not cause a buffer overrun and the return value is bound to the address of the byte after the last byte copied.
llvm-svn: 128677
|
| |
|
|
| |
llvm-svn: 128670
|
| |
|
|
|
|
| |
of the ASTReader is incomplete, leading to errors like not realizing std::type_info is already defined.
llvm-svn: 128664
|
| |
|
|
|
|
| |
automatically creating chained PCHs. This way, we don't get a crash whenever a diagnostic is emitted while processing the include.
llvm-svn: 128663
|
| |
|
|
| |
llvm-svn: 128641
|
| |
|
|
| |
llvm-svn: 128621
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
__block object copy/dispose helpers for C++ objects with those for
different variables with completely different semantics simply because
they happen to both be no more aligned than a pointer.
Found by inspection.
Also, internalize most of the helper generation logic within CGBlocks.cpp,
and refactor it to fit my peculiar aesthetic sense.
llvm-svn: 128618
|
| |
|
|
|
|
|
|
| |
wouldn't always be the final node, thus causing the state to continue propagating. Instead,
recover some path-sensitivity by conjuring a symbol.
llvm-svn: 128612
|
| |
|
|
|
|
| |
simulate constructors, but at least the analyzer doesn't think the return value is uninitialized.
llvm-svn: 128611
|
| |
|
|
|
|
| |
change.
llvm-svn: 128608
|
| |
|
|
| |
llvm-svn: 128607
|
| |
|
|
| |
llvm-svn: 128606
|
| |
|
|
|
|
| |
expression
llvm-svn: 128605
|
| |
|
|
|
|
|
| |
VCallAndVBaseOffsetBuilder::getCurrentOffsetOffset() to CharUnits. No change
in functionality intended.
llvm-svn: 128603
|
| |
|
|
|
|
|
| |
VCallAndVBaseOffsetBuilder::AddVBaseOffsets() to CharUnits. No change in
functionality intended.
llvm-svn: 128600
|
| |
|
|
|
|
| |
- Please never ever ever ever write a tool that sniffs this.
llvm-svn: 128599
|
| |
|
|
|
|
| |
constructor to CharUnits. No change in functionality intended.
llvm-svn: 128598
|
| |
|
|
|
|
|
| |
VCallAndVBaseOffsetBuilder::AddVCallAndVBaseOffsets() to
CharUnits. No change in functionality intended.
llvm-svn: 128596
|
| |
|
|
|
|
| |
into the Clang version.
llvm-svn: 128595
|
| |
|
|
| |
llvm-svn: 128590
|
| |
|
|
|
|
| |
<rdar://problem/9210154>.
llvm-svn: 128578
|
| |
|
|
|
|
|
|
|
|
|
| |
logic was divorced
from how we process ordinary function calls, had a tremendous about of redundancy, and relied
strictly on inlining behavior (which was incomplete) to provide semantics instead of falling
back to the conservative analysis we use for C functions. This is a significant step into
making C++ analyzer support more useful.
llvm-svn: 128557
|
| |
|
|
|
|
| |
Add a test case for synthesize ivar. // rdar://9070460
llvm-svn: 128554
|