Before:
1. Calling 'foo'
2. Doing something interesting
3. Returning from 'foo'
4. Some kind of error here
After:
1. Calling 'foo'
2. Doing something interesting
3. Returning from 'foo'
4. Some kind of error here
The location of the note is already in the caller, not the callee, so this
just brings the "depth" attribute in line with that.
This only affects plist diagnostic consumers (i.e. Xcode). It's necessary
for Xcode to associate the control flow arrows with the right stack frame.
<rdar://problem/13634363>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179351 91177308-0d34-0410-b5e6-96231b3b80d8
In this code
int getZero() {
return 0;
}
void test() {
int problem = 1 / getZero(); // expected-warning {{Division by zero}}
}
we generate these arrows:
+-----------------+
| v
int problem = 1 / getZero();
^ |
+---+
where the top one represents the control flow up to the first call, and the
bottom one represents the flow to the division.* It turns out, however, that
we were generating the top arrow twice, as if attempting to "set up context"
after we had already returned from the call. This resulted in poor
highlighting in Xcode.
* Arguably the best location for the division is the '/', but that's a
different problem.
<rdar://problem/13326040>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179350 91177308-0d34-0410-b5e6-96231b3b80d8
This is a Darwin-SDK-specific hash criteria used to identify a
particular SDK without having to hash the contents of all of its
headers. If other platforms have such versioned files, we should add
those checks here.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179346 91177308-0d34-0410-b5e6-96231b3b80d8
For struct-path aware TBAA, we used to use scalar type node as the scalar tag,
which has an incompatible format with the struct path tag. We now use the same
format: base type, access type and offset.
We also uniformize the scalar type node and the struct type node: name, a list
of pairs (offset + pointer to MDNode). For scalar type, we have a single pair.
These are to make implementaiton of aliasing rules easier.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179335 91177308-0d34-0410-b5e6-96231b3b80d8
This new option is the default, but it is useful to have a flag to override
-mno-implicit-float by putting -mimplicit-float later on the command line.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179309 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Handles all inheritance models for both data and function member
pointers.
Also implements isZeroInitializable() and refactors some of the null
member pointer code.
MSVC supports converting member pointers through virtual bases, which
clang does not (yet?) support. Implementing that extension is covered
by http://llvm.org/15713
Reviewers: rjmccall
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D613
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179305 91177308-0d34-0410-b5e6-96231b3b80d8
Function declarations are now broken with the following preferences:
1) break amongst arguments.
2) break after return type.
3) break after (.
4) break before after nested name specifiers.
Options #2 or #3 are preferred over #1 only if a substantial number of
lines can be saved by that.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179287 91177308-0d34-0410-b5e6-96231b3b80d8
The behavior can be overridden by setting LIT_USE_INTERNAL_SHELL=0 in
the environment.
This fixes issues with /dev/null for me and brings the test suite time
down to 30s. =D
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179283 91177308-0d34-0410-b5e6-96231b3b80d8
This required some tedious reordering to match clang's order.
Presumably these ObjC tests were generated based on llvm-gcc's output
ordering.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179282 91177308-0d34-0410-b5e6-96231b3b80d8
It's a kind of implicit conversion, which we generally drop, but
more importantly it's got very specific placement requirements.
rdar://13617051
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179254 91177308-0d34-0410-b5e6-96231b3b80d8
For this source:
const int &ref = someStruct.bitfield;
We used to generate this AST:
DeclStmt [...]
`-VarDecl [...] ref 'const int &'
`-MaterializeTemporaryExpr [...] 'const int' lvalue
`-ImplicitCastExpr [...] 'const int' lvalue <NoOp>
`-MemberExpr [...] 'int' lvalue bitfield .bitfield [...]
`-DeclRefExpr [...] 'struct X' lvalue ParmVar [...] 'someStruct' 'struct X'
Notice the lvalue inside the MaterializeTemporaryExpr, which is very
confusing (and caused an assertion to fire in the analyzer - PR15694).
We now generate this:
DeclStmt [...]
`-VarDecl [...] ref 'const int &'
`-MaterializeTemporaryExpr [...] 'const int' lvalue
`-ImplicitCastExpr [...] 'int' <LValueToRValue>
`-MemberExpr [...] 'int' lvalue bitfield .bitfield [...]
`-DeclRefExpr [...] 'struct X' lvalue ParmVar [...] 'someStruct' 'struct X'
Which makes a lot more sense. This allows us to remove code in both
CodeGen and AST that hacked around this special case.
The commit also makes Clang accept this (legal) C++11 code:
int &&ref = std::move(someStruct).bitfield
PR15694 / <rdar://problem/13600396>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179250 91177308-0d34-0410-b5e6-96231b3b80d8
The heuristic here (proposed by Jordan) is that, usually, if a leak is due to an early exit from init, the allocation site will be
a call to alloc. Note that in other cases init resets self to [super init], which becomes the allocation site of the object.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179221 91177308-0d34-0410-b5e6-96231b3b80d8
The escaping interaction between Python and grep doesn't work on my
system. This change fixes the tests for me.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179214 91177308-0d34-0410-b5e6-96231b3b80d8
commit was reverted in r179120, but I do plan on reapplying with a fix shortly.
Part of rdar://13611297
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179182 91177308-0d34-0410-b5e6-96231b3b80d8