llvm-svn: 174830

make sense anymore.

llvm-svn: 174829

llvm-svn: 174828

llvm-svn: 174827

type char, which can't have TBAA tags.

llvm-svn: 174826

llvm-svn: 174825

llvm-svn: 174824

llvm-svn: 174823

Use this to add a space after "@[" and before "]" for now.

Later, I want to use this to format multi-line array literals nicer, too.

llvm-svn: 174822

the "nonatomic" attribute in property redeclaration
in class extension. Also, improved on diagnostics in
this area while at it. // rdar://13156292

llvm-svn: 174821

llvm-svn: 174817

llvm-svn: 174816

llvm-svn: 174815

llvm-svn: 174814

The original syntax for the attribute groups was ambiguous. For example:

    declare void @foo() #1
    #0 = attributes { noinline }

The '#0' would be parsed as an attribute reference for '@foo' and not as a
top-level entity. In order to continue forward while waiting for a decision on
what the correct syntax is, I'm changing it to this instead:

     declare void @foo() #1
     attributes #0 = { noinline }

Repeat: This is TEMPORARY until we decide what the correct syntax should be.
llvm-svn: 174813

We are going to place the AttributeSet into a DenseMap during assembly writing.

llvm-svn: 174812

llvm-svn: 174811

This also gives us 0.2% speedup on '-fsyntax-only -Wdocumentation' time for
a testcase that consists of all Clang headers.

llvm-svn: 174810

llvm-svn: 174809

llvm-svn: 174808

llvm-svn: 174807

llvm-svn: 174806

These are causing assertions on some MSVC builds.

llvm-svn: 174805

llvm-svn: 174804

not enabled yet).

llvm-svn: 174803

There's no need to refer to the @implementation at all.

Fixes <rdar://problem/13186515>

llvm-svn: 174802

bitcode writer would generate abbrev records saying that the abbrev should be
filled with fixed zero-bit bitfields (this happens in the .bc writer when 
the number of types used in a module is exactly one, since log2(1) == 0).

In this case, just handle it as a literal zero.  We can't "just fix" the writer
without breaking compatibility with existing bc files, so have the abbrev reader
do the substitution.

Strengthen the assert in read to reject reads of zero bits so we catch such 
crimes in the future, and remove the special case designed to handle this.

llvm-svn: 174801

instead of always 32-bits at a time) with two changes:

1. Make Read(0) always return zero without affecting the state of our cursor.
2. Hack word_t to always be 32 bits, as staging.

These two caveats will change shortly.

llvm-svn: 174800

I'm using the name "Extended Identifiers" for the feature because that's
what GCC calls them. According to the standard, the new feature is
"universal character names are now allowed in identifiers", but the more
interesting "feature" is that identifiers can now contain Unicode characters,
however they are written.

llvm-svn: 174798

If you try to access any child > 0 without having touched child 0, LLDB won't be able to reconstruct type information from the debug info.
Previously, we would fail.
Now, we simply go fetch child 0 and then come back.

llvm-svn: 174795

visible.

The basic problem here is that a given translation unit can use
forward declarations to form pointers to a given type, say,

  class X;
  X *x;

and then import a module that includes a definition of X:

  import XDef;

We will then fail when attempting to access a member of X, e.g., 

  x->method()

because the AST reader did not know to look for a default of a class
named X within the new module.

This implementation is a bit of a C-centric hack, because the only
definitions that can have this property are enums, structs, unions,
Objective-C classes, and Objective-C protocols, and all of those are
either visible at the top-level or can't be defined later. Hence, we
can use the out-of-date-ness of the name and the identifier-update
mechanism to force the update.

In C++, we will not be so lucky, and will need a more advanced
solution, because the definitions could be in namespaces defined in
two different modules, e.g.,

  // module 1
  namespace N { struct X; }

  // module 2
  namespace N { struct X { /* ... */ }; }

One possible implementation here is for C++ to extend the information
associated with each identifier table to include the declaration IDs
of any definitions associated with that name, regardless of
context. We would have to eagerly load those definitions.

llvm-svn: 174794

Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where
hitting auto-continue signals while running a thread plan would cause us to lose control of the debug 
session.

<rdar://problem/12993641>

llvm-svn: 174793

llvm-svn: 174792

llvm-svn: 174791

llvm-svn: 174790

Handle chains in which the same offset is used for both loads and
stores to the same array.

Fixes rdar://11410078.

llvm-svn: 174789

Add warnings under -Wc++11-compat, -Wc++98-compat, and -Wc99-compat when a
particular UCN is incompatible with a different standard, and -Wunicode when
a UCN refers to a surrogate character in C++03.

llvm-svn: 174788

The missing definition check should be in the same category as the
missing ivar validation - in this case, the intent is to invalidate in
the given class, as described in the declaration, but the implementation
does not perform the invalidation. Whereas the MissingInvalidationMethod
checker checks the cases where the method intention is not to
invalidate. The second checker has potential to have a much higher false
positive rate.

llvm-svn: 174787

llvm-svn: 174786

line table entries in assembly.

llvm-svn: 174785