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

null before using it.

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

while deserializing a macro, make sure to copy/move what we need from it.

Fixes clang-x86_64-debian-fast bot.

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

Waiting for new llvm attribute code for the next step.



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

set on the cursor; return a null type in such a case.

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

Before: Constructor() : a(a), // comment a(a) {}
After:  Constructor() : a(a), // comment
                        a(a) {}

Needed this as a quick fix. Will add more tests for this in a future
commit.

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

Patch by Enea Zaffanella!

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

We used to incorrectly parse

aaaaaa ? aaaaaa(aaaaaa) : aaaaaaaa;

Due to an l_paren being followed by a colon, we assumed it to be part of
a constructor initializer. Thus, we never found the colon belonging to
the conditional expression, marked the line as bing incorrect and did
not format it.

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

Previously we would serialize the macro redefinitions as a list, part of
the identifier, and try to chain them together across modules individually
without having the info that they were already chained at definition time.

Change this by serializing the macro redefinition chain and then try
to synthesize the chain parts across modules. This allows us to correctly
pinpoint when 2 different definitions are ambiguous because they came from
unrelated modules.

Fixes bogus "ambiguous expansion of macro" warning when a macro in a PCH
is redefined without undef'ing it first.

rdar://13016031

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

Before: int x = ** a;
After:  int x = **a;

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

Various reasons seem to speak against it, so I am disabling this for
now.

Changed tests to still test this option.

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

"Bin-packing" here means allowing multiple parameters on one line, if a
function call/declaration is spread over multiple lines.

This is required by the Chromium style guide and probably desired for
the Google style guide. Not making changes to LLVM style as I don't have
enough data.

With this enabled, we format stuff like:
aaaaaaaaaaaaaaa(aaaaaaaaaa,
                aaaaaaaaaa,
		aaaaaaaaaaaaaaaaaaaaaaa).aaaaaaaaaaaaaaaaaa();

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