llvm-svn: 174814

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

These are causing assertions on some MSVC builds.

llvm-svn: 174805

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

Fixes <rdar://problem/13186515>

llvm-svn: 174802

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

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

llvm-svn: 174792

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: 174782

Separate the checking for the missing invalidation methods into a
separate checker so that it can be turned on/off independently.

llvm-svn: 174781

llvm-svn: 174780

The new annotation allows having methods that only partially invalidate
IVars and might not be called from the invalidation methods directly
(instead, are guaranteed to be called before the invalidation occurs).
The checker is going to trust the programmer to call the partial
invalidation method before the invalidator.This is common in cases when
partial object tear down happens before the death of the object.

llvm-svn: 174779

"auto-synthesized may not work correctly with 'nib' loader"
when 'readonly' property is redeclared 'readwrite' in class
extension. // rdar://13123861

llvm-svn: 174775

Should fix the MSC bot.

llvm-svn: 174769

Nearly all of these changes are one-to-one replacements; the few that
aren't have to do with custom identifier validation.

llvm-svn: 174768

I threw in a couple of test cases for UD-suffixes -- already working, but
it wasn't immediately obvious to me.

llvm-svn: 174767

This may not always be valid, but we were previously just
emitting them raw.

While here, s/isprint/isPrintable/ (using the new CharInfo).

llvm-svn: 174766

Rewriting the same predicates over and over again is bad for code size and
code maintainence. Using the functions in <ctype.h> is generally unsafe
unless they are specified to be locale-independent (i.e. only isdigit and
isxdigit).

The next commit will try to clean up uses of <ctype.h> functions within Clang.

llvm-svn: 174765

llvm-svn: 174759

llvm-svn: 174758

read another one, just as we do for types.

llvm-svn: 174745

llvm-svn: 174744

This correctly formats:
  {
    a;
  }
where { is incorrectly indented by 2, but is at level 0, when
reformatting only 'a;'.

llvm-svn: 174737

Fixes <rdar://problem/12322528>.

llvm-svn: 174736

'override' on the method.

This was fixed in a previous commit, generally handling attributes that are at the
end of the declaration.

rdar://13140589

llvm-svn: 174734

llvm-svn: 174730

involving property getter expressions on rhs of property setter.
// rdar://13138459

llvm-svn: 174729

Fixes llvm.org/PR14916.

llvm-svn: 174720

rewriting bug where #ifdef ended up on the same
line as the attribute declaration.

llvm-svn: 174719

They are much easier to handle when attached to the previous token.

Before:
unsigned Indent =
    formatFirstToken(TheLine.First, IndentForLevel[TheLine.Level] >=
                                    0 ? IndentForLevel[TheLine.Level]
: TheLine.Level * 2, TheLine.InPPDirective, PreviousEndOfLineColumn);

After:
unsigned Indent = formatFirstToken(
    TheLine.First, IndentForLevel[TheLine.Level] >= 0
                       ? IndentForLevel[TheLine.Level] : TheLine.Level * 2,
    TheLine.InPPDirective, PreviousEndOfLineColumn);

llvm-svn: 174718

With this patch, the formatter introduces 'fake' parenthesis according
to the operator precedence of binary operators.

Before:
return aaaa & AAAAAAAAAAAAAAAAAAAAAAAAAAAAA || bbbb &
       BBBBBBBBBBBBBBBBBBBBBBBBBBBBB || cccc & CCCCCCCCCCCCCCCCCCCCCCCCCC ||
       dddd & DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD;
f(aaaaaaaaaaaaaaaaaaaa && aaaaaaaaaaaaaaaaaaaa, aaaaaaaaaaaaaaaaaaaa &&
  aaaaaaaaaaaaaaaaaaaa, aaaaaaaaaaaaaaaaaaaa && aaaaaaaaaaaaaaaaaaaa);

After:
return aaaa & AAAAAAAAAAAAAAAAAAAAAAAAAAAAA ||
       bbbb & BBBBBBBBBBBBBBBBBBBBBBBBBBBBB ||
       cccc & CCCCCCCCCCCCCCCCCCCCCCCCCC ||
       dddd & DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD;
f(aaaaaaaaaaaaaaaaaaaa && aaaaaaaaaaaaaaaaaaaa,
  aaaaaaaaaaaaaaaaaaaa && aaaaaaaaaaaaaaaaaaaa,
  aaaaaaaaaaaaaaaaaaaa && aaaaaaaaaaaaaaaaaaaa);

Future improvements:
- Get rid of some of the hacky ways to nicely format certain constructs.
- Merge this parser and the AnnotatingParser as we now have several parsers
  that analyze (), [], etc.

llvm-svn: 174714

Before:
  [pboard setData:[NSData dataWithBytes:&button
                                 length:sizeof(button)]
          forType:kBookmarkButtonDragType];
After:
  [pboard setData:[NSData dataWithBytes:&button length:sizeof(button)]
          forType:kBookmarkButtonDragType];

llvm-svn: 174701

My previous attempt was extremely deficient, allowing more volatiles
to be introduced and not even checking all of the ones that are
present.

This attempt doesn't try to keep track of the values stored or offsets
within particular objects, just that the correct objects are accessed
in a correctly volatile manner throughout.

llvm-svn: 174700

Also, remove CLANG_BUILD_TESTS option. It won't have consistent behavior
between standalone and non-standalone builds, so I'm not going to bother
hooking it up for standalone builds. LLVM_BUILD_TESTS will continue to
control unit test inclusion in the "all" target in non-standalone builds.

Finally, fix the default value of CLANG_INCLUDE_TESTS, which was being set
to the boolean value of "LLVM_INCLUDE_TESTS", i.e. OFF, rather than actually
reading the variable ${LLVM_INCLUDE_TESTS}! If you picked up my earlier
commit, YOU WILL HAVE TO MANUALLY SET THIS OPTION BACK ON. My apologies!

Part two of r174691 (allow the unit tests to be built in standalone mode).

llvm-svn: 174698

included in the same test. Clang gets confused about whether it's already built
a module for this file, when running on a content-addressible filesystem.

llvm-svn: 174694

The reason this is not enabled by default is because there is no way for
Clang to guarantee that the LLVM unit testing infrastruture has been built.
However, if it /has/ been built, there's no reason why the standalone Clang
build can't use it!

This should have no effect on existing builds -- in a combined build the
value of the CLANG_INCLUDE_TESTS option defaults to the LLVM equivalent,
and in a standalone build it defaults to off.

llvm-svn: 174691

Fix conflict between r174685 and r174645 (rename -fmodule-cache-path <foo> to -fmodules-cache-path=<foo>).

llvm-svn: 174690