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

llvm-svn: 172679

llvm-svn: 172678

Reported on IRC by _savage

llvm-svn: 172677

llvm-svn: 172676

llvm-svn: 172675

llvm-svn: 172674

llvm-svn: 172673

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

llvm-svn: 172672

vector<bool> is specialized and the existing general summary for vectors would lie to the user.
Tackling libstdc++ and synthetic children is the following, less critical, part of this task

llvm-svn: 172671

llvm-svn: 172670

llvm-svn: 172669

Rewrapping courtesy of clang-format.

llvm-svn: 172668

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.

llvm-svn: 172667

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)

llvm-svn: 172666

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>.
 

llvm-svn: 172665

llvm-svn: 172664

Changing the Python reference document to be more explicit in discouraging usage of lldb.{debugger,...} convenience variables for formatters and other non-interactive Python extensions

llvm-svn: 172663

llvm-svn: 172662

llvm-svn: 172661

llvm-svn: 172660

llvm-svn: 172659

Moving the X86CostTable to a common place, so that other back-ends
can share the code. Also simplifying it a bit and commoning up
tables with one and two types on operations.

llvm-svn: 172658

    
Instead of writing the result of each transform to disk for every
transform, write the results to buffers in memory and pass those buffers
to the next transform as input. Only write the buffers to disk if the
final syntax check passes.

Reviewers: klimek
llvm-svn: 172657

llvm-svn: 172656

llvm-svn: 172655

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

llvm-svn: 172653

llvm-svn: 172652

llvm-svn: 172651

llvm-svn: 172650

initializations to fix Wreorder warning.

llvm-svn: 172649

llvm-svn: 172648

llvm-svn: 172647

llvm-svn: 172646

Patch by Jakub Staszak.

llvm-svn: 172645

llvm-svn: 172644

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

llvm-svn: 172643

llvm-svn: 172642

llvm-svn: 172641

llvm-svn: 172640

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

llvm-svn: 172639