llvm-svn: 137750

llvm-svn: 137740

llvm-svn: 137736

llvm-svn: 137720

[analyzer] Enhance ConditionVisitor to handle arbitrary ValueDecls in binary expressions, and also handle inverting the order of comparison when the named decl appears on the RHS.

llvm-svn: 137714

...I believe it would not break anything...

FIXME: "check-all" may not be generated w/o LLVM_INCLUDE_TESTS.
llvm-svn: 137709

llvm-svn: 137708

[analyzer] Enhance ConditionVisitor to understand eagerly evaluated (simple) binary conditions, and teach it to only focus on constraint changes.

llvm-svn: 137705

[analyzer] add ExprEngine::getEagerlyAssumedTags() to allow externally querying of "eagerly assumed" expressions.

llvm-svn: 137704

llvm-svn: 137697

llvm-svn: 137688

llvm-svn: 137682

MacOSKeychainAPIChecker: The security API/memory leak checker should always generate regular nodes instead of sink nodes.

llvm-svn: 137681

llvm-svn: 137677

llvm-svn: 137676

llvm-svn: 137674

llvm-svn: 137671

fail if a TypeLoc kind is not handled) and handle DecltypeTypeLoc and InjectedClassNameTypeLoc.

llvm-svn: 137670

test over from llvm/test/FrontendC++ and update others to account for
the change.

llvm-svn: 137669

Take 2 (take 3?) at removing derelict clang.xcodeproj.  All Xcode users should be using CMake, as the clang.xcodeproj is never up-to-date and cannot actually build Clang.

llvm-svn: 137666

llvm-svn: 137665

llvm-svn: 137660

llvm-svn: 137653

Outside the driver, they were already treated that way, but the driver was not
giving them the same special treatment as -fapple-kext, e.g., falling back to
llvm-gcc for i386/Darwin kexts.  Radar 9868422.

llvm-svn: 137639

llvm-svn: 137638

llvm-svn: 137634

MacOSKeychainAPIChecker: Use llvm::SmallString instead of std::string (as per code review for r137523).

llvm-svn: 137633

llvm-svn: 137620

conversion to initialize the standard conversion *after* the
user-defined conversion properly. Fixes PR10644.

llvm-svn: 137608

llvm-svn: 137592

llvm-svn: 137591

llvm-svn: 137585

llvm-svn: 137574

Implement function template specialization at class scope extension in Microsoft mode. A new AST node is introduced: ClassScopeFunctionSpecialization. This node holds a FunctionDecl that is not yet specialized; then during the class template instantiation the ClassScopeFunctionSpecialization will spawn the actual function specialization.

Example:
template <class T>
class A {
public:
  template <class U> void f(U p) {  }
  template <> void f(int p) {  } // <== class scope specialization
};

This extension is necessary to parse MSVC standard C++ headers, MFC and ATL code.
BTW, with this feature in, clang can parse (-fsyntax-only) all the MSVC 2010 standard header files without any error.

llvm-svn: 137573

In fact, they are false warnings but it seems g++-4.4 might be unable to know they must be false.

llvm-svn: 137568

Since -mkernel implies -fapple-kext, this just extends the current behavior
for -fapple-kext to apply for -mkernel as well.  Radar 9933387.

llvm-svn: 137566

Matches gcc, and is also required for using ccache with clang.

llvm-svn: 137563

This is the ObjC++ version of r129201. It's for example needed to use
ccache with clang.

llvm-svn: 137560

llvm-svn: 137552

Unlike most of the other Neon intrinsics, these are not overloaded and do not
have the extra argument that specifies the vector type.  This has not been
fatal because the lane number operand is supposed to be an ICE and so that
value has harmlessly been used as the type identifier.  Radar 9901281.

llvm-svn: 137550