git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199984 91177308-0d34-0410-b5e6-96231b3b80d8

This was done when we were not able to parse lambdas to handle some
edge cases for block formatting different in return statements, but is
not necessary any more.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199982 91177308-0d34-0410-b5e6-96231b3b80d8

of the differences we identified here have been fixed by improvements in GCC.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199970 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199964 91177308-0d34-0410-b5e6-96231b3b80d8

override for the type of 'this', also clear it out (unless we're entering the
context of a lambda-expression, where it should be inherited).


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199962 91177308-0d34-0410-b5e6-96231b3b80d8

Differential Revision: http://llvm-reviews.chandlerc.com/D2606

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199958 91177308-0d34-0410-b5e6-96231b3b80d8

member-declaration. In the process, fix a couple of bugs that had crept in
where we would parse the first and subsequent member-declarators differently
(in particular, we didn't accept an asm-label on a member function definition
within a class, and we would accept virt-specifiers and attributes in the wrong
order on the first declarator but not on subsequent ones).


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199957 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199956 91177308-0d34-0410-b5e6-96231b3b80d8

This returns a list of valid (and useful) completions for a context (a list
of outer matchers), ordered by decreasing relevance then alphabetically. It
will be used by the matcher parser to implement completion.

Differential Revision: http://llvm-reviews.chandlerc.com/D2210

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199950 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199949 91177308-0d34-0410-b5e6-96231b3b80d8

The declarations seem correct, but the definitions were using
chars instead of shorts.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199923 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199910 91177308-0d34-0410-b5e6-96231b3b80d8

The tests (forgot to svn add, sorry!).

Patch from Fraser Cormack!



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199907 91177308-0d34-0410-b5e6-96231b3b80d8

Patch from Fraser Cormack!



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199906 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199904 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199903 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199902 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199901 91177308-0d34-0410-b5e6-96231b3b80d8

Due to statement expressions supported as GCC extension, it is possible
to put 'break' or 'continue' into a loop/switch statement but outside
its body, for example:

    for ( ; ({ if (first) { first = 0; continue; } 0; }); )

This code is rejected by GCC if compiled in C mode but is accepted in C++
code. GCC bug 44715 tracks this discrepancy. Clang used code generation
that differs from GCC in both modes: only statement of the third
expression of 'for' behaves as if it was inside loop body.

This change makes code generation more close to GCC, considering 'break'
or 'continue' statement in condition and increment expressions of a
loop as it was inside the loop body. It also adds error for the cases
when 'break'/'continue' appear outside loop due to this syntax. If
code generation differ from GCC, warning is issued.

Differential Revision: http://llvm-reviews.chandlerc.com/D2518


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199897 91177308-0d34-0410-b5e6-96231b3b80d8

This is a simpler rule, broadly in line with previous Darwin (which chose
between "soft" and "softfp") but probably safer. In practice the only real
reason for "softfp" is ABI compatibility, not usually an issue on limited chips
like these, so anyone who wanted hard-float should already be saying so.

That's my story and I'm sticking to it.

rdar://problem/15887493

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199896 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199894 91177308-0d34-0410-b5e6-96231b3b80d8

More universal way of removing trailing whitespace characters then 'chomp' does. Chomp "removes any trailing string that corresponds to the current value of $/" (quote from perldoc). In my case an input ended with '\r\r\n', chomp left '\r' at the end of input and the script ended up with an error "Use of uninitialized value in concatenation (.) or string"

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199892 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199875 91177308-0d34-0410-b5e6-96231b3b80d8

Some ABIs have different return types for constructors and
destructors, and we're just looking for the end of the function
here. Loosen up the regex.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199870 91177308-0d34-0410-b5e6-96231b3b80d8

If there are non-trivially-copyable types /other/ than C++ records, we
won't have a synthesized copy expression, but we can't just use a simple
load/return.

Also, add comments and shore up tests, making sure to test in both ARC
and non-ARC.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199869 91177308-0d34-0410-b5e6-96231b3b80d8

Now we'll get a warning if we miss a case. Refinement of r199800.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199868 91177308-0d34-0410-b5e6-96231b3b80d8

match argument type.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199867 91177308-0d34-0410-b5e6-96231b3b80d8

As vcles_f32() and vcled_f64 are implemented by FCMGE, operands
should make a swap.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199866 91177308-0d34-0410-b5e6-96231b3b80d8

This adds tests for both logical or and for logical and, which was
already correct.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199865 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199864 91177308-0d34-0410-b5e6-96231b3b80d8

This test requires asserts for now, and exception handling has an
awkward structure that leads to extra run lines. Because of this, the
test file's not a great place for other C++ PGO tests, but
instr-profile.cpp is obviously the better name for them.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199863 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199862 91177308-0d34-0410-b5e6-96231b3b80d8

Removes some old code that allowed a module to be loaded from a pcm file
even if the module.map could not be found.  Also update a number of
tests that relied on the old behavior.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199852 91177308-0d34-0410-b5e6-96231b3b80d8

create an implicit declaration of it (because some type it depends on is
unavailable). This had the effect of causing us to not implicitly give it the
right attributes. It turns out that glibc's __sigsetjmp is declared before
sigjmp_buf is declared, and this resulted in us not implicitly giving it
__attribute__((returns_twice)), which in turn resulted in miscompiles in any C
code calling glibc's sigsetjmp.

(See also the vaguely-related sourceware.org/PR4662.)


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199850 91177308-0d34-0410-b5e6-96231b3b80d8

If an attribute has a semantically meaningful spelling (such as ArgumentWithTypeTagAttr or MSInheritanceAttr), display the spelling used for the attribute as part of the AST dump. This should ease debugging the AST for these attributes. Attributes without semantically meaningful spelling variations are not affected.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199834 91177308-0d34-0410-b5e6-96231b3b80d8

PNaCl and Emscripten can both handle va_arg IR instructions with
struct type.

Also add a test to cover generating a va_arg IR instruction from
va_arg in C on le32 (as already handled by VisitVAArgExpr() in
CGExprScalar.cpp), which was not covered by a test before.

(This fixes https://code.google.com/p/nativeclient/issues/detail?id=2381)

Differential Revision: http://llvm-reviews.chandlerc.com/D2539

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199830 91177308-0d34-0410-b5e6-96231b3b80d8

the defaulting because it would delete the member, produce additional notes
explaining why the member is implicitly deleted.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199829 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199828 91177308-0d34-0410-b5e6-96231b3b80d8

(to go with existing suppression of -Wa,-compress-debug-sections)

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199822 91177308-0d34-0410-b5e6-96231b3b80d8

not using backing ivar warning, ignore when
property is not being synthesized (user declared its
implementation @dynamic). // rdar://1583425


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199820 91177308-0d34-0410-b5e6-96231b3b80d8