* Treat compound assignment as a use, at Jordy's request.
 * Always add compound assignments into the CFG, so we can correctly diagnose the use in 'return x += 1;'

llvm-svn: 160334

llvm-svn: 160332

llvm-svn: 160331

use out of TransferFunctions, and compute it in advance rather than on-the-fly.

This allows us to handle compound assignments with DeclRefExprs on the RHS
correctly, and also makes it trivial to treat const& function parameters as not
initializing the argument. The patch also makes both of those changes.

llvm-svn: 160330

<rdar://problem/11818967>

llvm-svn: 160328

This should fix the failure on Windows.

llvm-svn: 160324

llvm-svn: 160323

llvm-svn: 160322

when using Python < 2.7.0.  This is the case on Snow Leopard, where the tools are always
installed in /Developer.  This isn't a proper fix for really figuring out where Xcode
is installed, but should work to fix an obvious problem on Snow Leopard.

llvm-svn: 160321

llvm-svn: 160320

This code is very sensitive to the difference between "columns" as printed
and "bytes" (SourceManager columns). All variables are now named explicitly
and our assumptions are (hopefully) documented as both comment and assertion.

Whether parseable fixits should use byte offsets or Unicode character counts
is pending discussion on the mailing list; currently the implementation uses
bytes (and has no problems on lines containing multibyte characters).
This has been added to the user manual.

<rdar://problem/11877454>

llvm-svn: 160319

Found while investigating PR13330

llvm-svn: 160318

llvm-svn: 160315

CmpRuns can be used for static analyzer bug report comparison. However,
we want to make sure external users do not rely on the way bugs are
represented (plist files). Make sure that we have a user
friendly/documented API for CmpRuns script.

llvm-svn: 160314

llvm-svn: 160313

llvm-svn: 160309

This function has two versions. The first one is used for a register operand.
The second one is used for an immediate number.

llvm-svn: 160308

Review by Richard Smith.

llvm-svn: 160306

<string.h>. // rdar://11847319

llvm-svn: 160287

Fixing an MSVC warning -- the compiler did not like the cast added to work around a g++ bug (it would claim to possibly emit incorrect code).

llvm-svn: 160281

llvm-svn: 160268

The new clang-ast-dump tool for selective AST dumping. Moved common command-line tool stuff to CommandLineClangTool

llvm-svn: 160265

llvm-svn: 160264

llvm-svn: 160263

llvm-svn: 160257

llvm-svn: 160255

CXXFunctionalCastExprs.

llvm-svn: 160252

llvm-svn: 160247

pattern might be an alias template which doesn't use its arguments). It's always
instantiation-dependent, though.

llvm-svn: 160246

as an array of its base class TemplateArgument. Switch the const
TemplateArgument* parameters of InstantiatingTemplate's constructors to
ArrayRef<TemplateArgument> to prevent this from happening again in the future.

llvm-svn: 160245

being a property of a canonical type to being a property of the fully-sugared
type. This should only make a difference in the case where an alias template
ignores one of its parameters, and that parameter is an unexpanded parameter
pack.

llvm-svn: 160244

llvm-svn: 160241

has a much lower default stack limit than the systems I have access to.

llvm-svn: 160240

llvm-svn: 160238

llvm-svn: 160236

Patch by Sam Panzer!

llvm-svn: 160233

llvm-svn: 160231

struct __attribute__((visibility("hidden"))) zed {
};
struct __attribute__((visibility("hidden"))) zed;

Which is a bit silly and got a lot noisier now that we correctly handle
visibility pragmas. This patch fixes that and also has some extra quality
improvements:

* We now produce an error instead of a warning for

struct __attribute__((visibility("hidden"))) zed {
};
struct __attribute__((visibility("default"))) zed;

* The "after definition" warning now points to the new attribute that is
  ignored instead of pointing to the declaration.

llvm-svn: 160227

llvm-svn: 160226

Finishes rdar://11875995

llvm-svn: 160225