Before:
void aaaaaaaaaaaa(int aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa) const GUARDED_BY(
    aaaaaaaaaaaaa);

After:
void aaaaaaaaaaaa(int aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa) const
    GUARDED_BY(aaaaaaaaaaaaa);

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

-fopenmp in the link step on Linux. There is probably more tweaking that
will need to take place to get good support for linking the relevant
libraries on all Linux distributions and/or on other platforms, but this
get's the ball moving and allows Clang to build programs which contain
OpenMP pragmas that can be safely ignored by a compiler that doesn't
implement them, and yet makes direct calls into the OpenMP runtime.

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

Also adding more tests.

We can now keep the formatting of something like:

static SomeType type = { aaaaaaaaaaaaaaaaaaaa, /* comment */
                         aaaaaaaaaaaaaaaaaaaa /* comment */,
                         /* comment */ aaaaaaaaaaaaaaaaaaaa,
                         aaaaaaaaaaaaaaaaaaaa, // comment
                         aaaaaaaaaaaaaaaaaaaa };

Note that the comment in the first line is handled like a trailing line comment
as that is likely what the user intended.

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

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

clang/test/Index/code-completion-skip-bodies.cpp: Check stdout and stderr individually, rather than mixed output of stdout and stderr with 2>&1.

XFAIL(s) are removed.

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

r172140 changed the formatter to produce "-(id) foo" instead of "- (id)foo"
in google style, with a link to
http://google-styleguide.googlecode.com/svn/trunk/objcguide.xml#Method_Declarations_and_Definitions
as reference.  But now that I look at that link again, it seems I didn't
read it very carefully the first time round.



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

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

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

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

This is inspired by a number of false positives in real code, including
PR14968. I've added test cases reduced from these false positives to
test/Sema/unused-expr.c, as well as corresponding test cases that pass the
offending expressions as arguments to a no-op macro to ensure that we do warn
there.

This also removes my previous tweak from r166522/r166534, so that we warn on
unused cast expressions in macro arguments.

There were several test cases that were using -Wunused-value to test general
diagnostic emission features; I changed those to use other warnings or warn on
a macro argument expression. I stared at the test case for PR14399 for a while
with Richard Smith and we believe the new test case exercises the same
codepaths as before.

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

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

literals. As suggested by Sean Silva.


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

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

in the LangRef).

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

it apart from [[gnu::noreturn]] / __attribute__((noreturn)), since their
semantics are not equivalent (for instance, we treat [[gnu::noreturn]] as
affecting the function type, whereas [[noreturn]] does not).


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

expressions which have undefined behavior due to multiple unsequenced
modifications or an unsequenced modification and use of a variable.


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

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

undefined, and don't find methods or protocols within those protocol
definitions. This completes <rdar://problem/10634711>.


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

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

produce more inline layout metadata. // rdar://12752901


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

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

if we can see the elements of the arrays.

for example:

 NSDictionary *dict = [NSDictionary dictionaryWithObjects:[NSArray arrayWithObjects:@"1", @"2", nil] forKeys:[NSArray arrayWithObjects:@"A", @"B", nil]];

-->

 NSDictionary *dict = @{ @"A" : @"1", @"B" : @"2" };

rdar://12428166

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

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

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

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

echristo already fixed this in r172649, but I'll leave the reformatting in
since I'm in the blame history for it now anyway.

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

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

Rewrapping courtesy of clang-format.

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

This fixes pr14946. The problem was that the linkage computation was done too
early, so things like "extern int a;" would be given external linkage, even if
a previous declaration was static.

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

Several of the intrinsic headers were using plain non-reserved identifiers.
C++11 17.6.4.3.2 [global.names] p1 reservers names containing a double
begining with an underscore followed by an uppercase letter for any use.

I think I got them all, but open to being corrected. For the most part I
didn't bother updating function-like macro parameter names because I don't
believe they're subject to any such collission - though some function-like
macros already follow this convention (I didn't update them in part because
the churn was more significant as several function-like macros use the double
underscore prefixed version of the same name as a parameter in their
implementation)

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

consider (sub)module visibility.

The bulk of this change replaces myriad hand-rolled loops over the
linked list of Objective-C categories/extensions attached to an
interface declaration with loops using one of the four new category
iterator kinds:

  visible_categories_iterator: Iterates over all visible categories
  and extensions, hiding any that have their "hidden" bit set. This is
  by far the most commonly used iterator.

  known_categories_iterator: Iterates over all categories and
  extensions, ignoring the "hidden" bit. This tends to be used for
  redeclaration-like traversals.

  visible_extensions_iterator: Iterates over all visible extensions,
  hiding any that have their "hidden" bit set.

  known_extensions_iterator: Iterates over all extensions, whether
  they are visible to normal name lookup or not.

The effect of this change is that any uses of the visible_ iterators
will respect module-import visibility. See the new tests for examples.

Note that the old accessors for categories and extensions are gone;
there are *Raw() forms for some of them, for those (few) areas of the
compiler that have to manipulate the linked list of categories
directly. This is generally discouraged.

Part two of <rdar://problem/10634711>.
 



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

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

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

I think the main issue was the lack of -ffreestanding, which pulled in
the host's stdint.h. After that things went rapidly downhill.

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

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

initializations to fix Wreorder warning.

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

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

Adding verbiage to the Language Extensions document about __has_include and __has_include_next only being allowed within preprocessor directives.

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

No longer crashing with an assert when __has_include or __has_include_next is used outside of a preprocessor directive.  This fixes PR14837.

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

when the methods are declared in a submodule that has not yet been
imported. Part of <rdar://problem/10634711>. 


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