llvm-svn: 172130

llvm-svn: 172129

This fixes va_start/va_copy of a va_list field which happens to not
be laid out at a 16-byte boundary.

Differential Revision: http://llvm-reviews.chandlerc.com/D276

llvm-svn: 172128

Truncation happens regularly when find_first_not_of returns npos,
strings long enough to trigger bug here are implausible.

No functionality change intended (ignoring absurd string lengths).

llvm-svn: 172127

llvm-svn: 172126

llvm-svn: 172125

llvm-svn: 172124

llvm-svn: 172123

Part of rdar://12991541

llvm-svn: 172122

Part of rdar://12991541

llvm-svn: 172121

Decl is a VarDecl.
Part of rdar://12991541

llvm-svn: 172120

Providing data formatters for char16_t* and char32_t* C++11-style Unicode strings
Using this chance to refactor the UTF data reader used for data formatters for added generality
Added a relevant test case

llvm-svn: 172119

llvm-svn: 172118

Teach InstCombine to hoist FABS and FNEG through FPTRUNC instructions.  The application of these operations commutes with the truncation, so we should prefer to do them in the smallest size we can, to save register space, use smaller constant pool entries, etc.

llvm-svn: 172117

llvm-svn: 172115

llvm-svn: 172114

llvm-svn: 172112

Before:
@property(assign, getter = isEditable) BOOL editable;

Now:
@property(assign, getter=isEditable) BOOL editable;

It'd be nice if some Apple person could let me know if spaces are preferred
around '=' in @synthesize lines (see FIXME in the test).

llvm-svn: 172110

against the developer policy to include this sort of thing as SVN blame
already captures this in a far more fine-grained way.

llvm-svn: 172109

llvm-svn: 172108

llvm-svn: 172107

llvm-svn: 172105

Restructured the checker so that it could easily find two new classes of
issues:
 - when a class contains an invalidatable ivar, but no declaration of an
invalidation method
 - when a class contains an invalidatable ivar, but no definition of an
invalidation method in the @implementation.

The second case might trigger some false positives, for example, when
the method is defined in a category.

llvm-svn: 172104

llvm-svn: 172103

// rdar://11577384

llvm-svn: 172102

llvm-svn: 172101

llvm-svn: 172100

Don't do this in Google style though:
http://google-styleguide.googlecode.com/svn/trunk/objcguide.xml#Protocols

Most other places (function declarations, variable declarations) still get
this wrong, and since this looks very similiar to template instantiations to
the lexer (`id <MyProtocol> a = ...`), it's going to be hard to fix in some
places.

llvm-svn: 172099

This is the last step of pure shuffling stuff around, the next step will
be the actual feature.

llvm-svn: 172098

llvm-svn: 172097

llvm-svn: 172096

Before:
@ -4.5

Now:
@-4.5

llvm-svn: 172095

llvm-svn: 172094

The first token in @implementation, @interface, and @protocol lines is now
marked TT_ObjCDecl, and lines starting with a TT_ObjCDecl token are now marked
LT_ObjCMethodDecl.

llvm-svn: 172093

This is the next step towards being able to configure multiple unwrapped
lines into one.

llvm-svn: 172092

an objectiveC object, use objc_exception_throw
to raise the exception. // rdar://12605907

llvm-svn: 172091

llvm-svn: 172090

-provide a "raw_ostream'ish" class to make it convenient to output logging info.
-use macros to automate a bit the logging functionality inside libclang functions
-when logging, print a stack trace if "LIBCLANG_LOGGING=2" environment is set.
-add logging to more functions.

llvm-svn: 172089

This will be a new style requirement going forwards: a diagnostic can only
use the implicit InGroup<DiagGroup<"foo">> syntax if "foo" is not used by
any other diagnostics; as soon as it is, it needs an explicit group.

This also brings some stray "conversion" diagnostics into the
"Value Conversion Issue" category, instead of the more generic
"Semantic Issue" category. I consider this an improvement!
- warn_impcast_complex_scalar
- warn_impcast_float_integer
- warn_impcast_float_precision
- warn_impcast_integer_precision
- warn_impcast_vector_scalar

llvm-svn: 172088

Not only is this inefficient for TableGen, it's annoying for maintenance
when renaming warning flags (unusual) or adding those flags to a group
(more likely).

This uses the new fix-it infrastructure for LLVM's SourceMgr/SMDiagnostic,
as well as a few changes to TableGen to track more source information.

llvm-svn: 172087