<rdar://problem/13037793> Allow the names of modules to differ from the name of their subdirectory in the include path.

llvm-svn: 177621

enum return type to be converted to blocks with any integer type
of the same size.

rdar://13463504

llvm-svn: 177613

Testing cases for structs of structs and unions of structs.

llvm-svn: 177612

This isn't necessary & with the next change to LLVM the DW_TAG_file_type entry
won't be emitted at all - only the raw filename/directory pair, so match on
that directly instead.

llvm-svn: 177609

 * libclang_rt-san-* is sanitizer_common, and is linked in only if no other
   sanitizer runtime is present.
 * libclang_rt-ubsan-* is the piece of the runtime which doesn't depend on
   a C++ ABI library, and is always linked in.
 * libclang_rt-ubsan_cxx-* is the piece of the runtime which depends on a
   C++ ABI library, and is only linked in when linking a C++ binary.

This change also switches us to using -whole-archive for the ubsan runtime
(which is made possible by the above split), and switches us to only linking
the sanitizer runtime into the main binary and not into DSOs (which is made
possible by using -whole-archive).

The motivation for this is to only link a single copy of sanitizer_common
into any binary. This is becoming important now because we want to share
more state between multiple sanitizers in the same process (for instance,
we want a single shared output mutex).

The Darwin ubsan runtime is unchanged; because we use a DSO there, we don't
need this complexity.

llvm-svn: 177605

Reviewers: rjmccall

CC: timurrrr, llvm-commits

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

llvm-svn: 177589

llvm-svn: 177583

* Clarify what MacroInfo::isBuiltinMacro means, as it really means something
  more like "isMagicalMacro" or "requiresProcessingBeforeExpansion" -- the
  macros defined in "<built-in>" are not considered built-in by this function;
* Escape __LINE__ as \__LINE__ in Doxygen comments so that the underscores
  don't get replaced by *bold* output;
* Turn comments in MacroInfo.cpp into non-Doxygen comments, so that they
  don't result in duplicated/badly formatted Doxygen output;
* Clean up a bunch of \brief formatting, and add a \file comment for
  MacroInfo.h.

llvm-svn: 177581

<rdar://problem/12368093> Extend module maps with a 'conflict' declaration, and warn when a newly-imported module conflicts with an already-imported module.

llvm-svn: 177577

This fixes some mistaken condition logic in RegionStore that caused
global variables to be invalidated when /any/ region was invalidated,
rather than only as part of opaque function calls. This was only
being used by CStringChecker, and so users will now see that strcpy()
and friends do not invalidate global variables.

Also, add a test case we don't handle properly: explicitly-assigned
global variables aren't being invalidated by opaque calls. This is
being tracked by <rdar://problem/13464044>.

llvm-svn: 177572

Due to improper modelling of copy constructors (specifically, their
const reference arguments), we were producing spurious leak warnings
for allocated memory stored in structs. In order to silence this, we
decided to consider storing into a struct to be the same as escaping.
However, the previous commit has fixed this issue and we can now properly
distinguish leaked memory that happens to be in a struct from a buffer
that escapes within a struct wrapper.

Originally applied in r161511, reverted in r174468.
<rdar://problem/12945937>

llvm-svn: 177571

In this case, the value of 'x' may be changed after the call to indirectAccess:

  struct Wrapper {
    int *ptr;
  };

  void indirectAccess(const Wrapper &w);

  void test() {
    int x = 42;
    Wrapper w = { x };

    clang_analyzer_eval(x == 42); // TRUE
    indirectAccess(w);
    clang_analyzer_eval(x == 42); // UNKNOWN
  }

This is important for modelling return-by-value objects in C++, to show
that the contents of the struct are escaping in the return copy-constructor.

<rdar://problem/13239826>

llvm-svn: 177570

This is a bit of old code trying to deal with the fact that functions that
take pointers often use them to access an entire array via pointer
arithmetic. However, RegionStore already conservatively assumes you can use
pointer arithmetic to access any part of a region.

Some day we may want to go back to handling this specifically for calls,
but we can do that in the future.

No functionality change.

llvm-svn: 177569

(this is a paired commit with an LLVM change to DIBuilder - expect some
buildbot skew/fallout)

llvm-svn: 177565

The #line directive is mostly for backend testing (keeping these files matching
should simplify maintenance somewhat) though the corresponding backend test
improvement/update doesn't verify the file information directly just yet.
Coming in a later iteration.

llvm-svn: 177559

I am not sure how much we can improve for
when a randon ObjC keyword is thrown into the
ivar decl. block. // rdar://6854840

llvm-svn: 177553

llvm-svn: 177552

And ask for people to try it out and send us bug reports!

llvm-svn: 177551

'}' is missing for the ivar declarations.
// rdar://6854840

llvm-svn: 177549

Fix by Ismail Pazarbasi (ismail.pazarbasi@gmail.com), review by Dmitri Gribenko.

llvm-svn: 177546

llvm-svn: 177544

Only introduce the SDKSettings.plist dependency in modules/PCH files that don't depend on any other modules or PCH files.

llvm-svn: 177542

For constructors/desctructors that return 'this', if there exists a callsite
that returns 'this' and is immediately before the return instruction, make
sure we are using the return value from the callsite.

We don't need to keep 'this' alive through the callsite. It also enables
optimizations in the backend, such as tail call optimization.

Updated from r177211.
rdar://12818789

llvm-svn: 177541

Summary: Added support for pointers-to-members usage via .* and a few tests.

Reviewers: djasper

Reviewed By: djasper

CC: cfe-commits, klimek

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

llvm-svn: 177537

clang-format can't do anything useful, so it should leave the remainder
of the line unchanged, but it should not assert/segfault.

llvm-svn: 177530

Discovered when accidentally formatting a python file :-).

llvm-svn: 177527

Before (when only reformatting "int b"):
int a; // comment
       // comment
       int b;

After:
int a; // comment
       // comment
int b;

This also fixes llvm.org/PR15433.

llvm-svn: 177524

Before:
  aaaaaaaaaaaaaaaaa(aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa +
                    aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,
                    aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);
After:
  aaaaaaaaaaaaaaaaa(
      aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa + aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,
      aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);

llvm-svn: 177521

This seems to be generally more desired.

Before:
if (aaaaaaaa &&
    bbbbbbbb >
    cccccccc) {}
After:
if (aaaaaaaa &&
    bbbbbbbb >
        cccccccc) {}

Also: Some formatting cleanup on clang-format's files.
llvm-svn: 177514

Otherwise, this can become hard to read.

Before: #define A \
        case 1:
After:  #define A \
           case 1:
llvm-svn: 177509

llvm-svn: 177506

Before: A<int * (int)>;
After:  A<int *(int)>;
llvm-svn: 177505

We were checking "Arch == llvm::Triple::x86_64 || Arch
== llvm::Triple::x86_64", but the rhs should actually check for
powerpc64.

Found while experimenting with a potential new Clang warning.

llvm-svn: 177496

llvm-svn: 177491

Patch by Stephen Lin!

llvm-svn: 177490

The backend portion of this test will be committed to LLVM's test suite.

llvm-svn: 177485

This fixes regressions introduced in r177466 that caused several
module tests to fail sporadically.

llvm-svn: 177481

llvm-svn: 177480

Each toolchain has a set of tools, but they are all of known types. It can
have a linker, an assembler, a "clang" (compile, analyze, ...) a non-clang
compiler, etc.

Instead of keeping a map, just have member variable for each type of tool.

llvm-svn: 177479

emit function names in .gcda files by default, and the flag turns that off!
Rename the flag to make it match what it actually does. This keeps the default
format compatible with gcc 4.2.

Also add a test for this flag.

llvm-svn: 177475