Remove upstream files and directories from vendor/clang/dist that we do

not use.  This saves on repository space, and reduces the number of tree
conflicts when merging.

5 files changed, 0 insertions, 353 deletions

diff --git a/lib/StaticAnalyzer/CMakeLists.txt b/lib/StaticAnalyzer/CMakeLists.txt
deleted file mode 100644
index 3d1509254f52..000000000000
--- a/lib/StaticAnalyzer/CMakeLists.txt
+++ /dev/null
@@ -1,3 +0,0 @@
-add_subdirectory(Core)
-add_subdirectory(Checkers)
-add_subdirectory(Frontend)
diff --git a/lib/StaticAnalyzer/Checkers/CMakeLists.txt b/lib/StaticAnalyzer/Checkers/CMakeLists.txt
deleted file mode 100644
index 10fb0bd3536c..000000000000
--- a/lib/StaticAnalyzer/Checkers/CMakeLists.txt
+++ /dev/null
@@ -1,112 +0,0 @@
-set(LLVM_LINK_COMPONENTS
-  Support
-  )
-
-add_clang_library(clangStaticAnalyzerCheckers
-  AnalysisOrderChecker.cpp
-  AnalyzerStatsChecker.cpp
-  ArrayBoundChecker.cpp
-  ArrayBoundCheckerV2.cpp
-  BasicObjCFoundationChecks.cpp
-  BlockInCriticalSectionChecker.cpp
-  BoolAssignmentChecker.cpp
-  BuiltinFunctionChecker.cpp
-  CStringChecker.cpp
-  CStringSyntaxChecker.cpp
-  CallAndMessageChecker.cpp
-  CastSizeChecker.cpp
-  CastToStructChecker.cpp
-  CheckObjCDealloc.cpp
-  CheckObjCInstMethSignature.cpp
-  CheckSecuritySyntaxOnly.cpp
-  CheckSizeofPointer.cpp
-  CheckerDocumentation.cpp
-  ChrootChecker.cpp
-  CloneChecker.cpp
-  ConversionChecker.cpp
-  CXXSelfAssignmentChecker.cpp
-  DeadStoresChecker.cpp
-  DebugCheckers.cpp
-  DeleteWithNonVirtualDtorChecker.cpp
-  DereferenceChecker.cpp
-  DirectIvarAssignment.cpp
-  DivZeroChecker.cpp
-  DynamicTypePropagation.cpp
-  DynamicTypeChecker.cpp
-  EnumCastOutOfRangeChecker.cpp
-  ExprInspectionChecker.cpp
-  FixedAddressChecker.cpp
-  GCDAntipatternChecker.cpp
-  GenericTaintChecker.cpp
-  GTestChecker.cpp
-  IdenticalExprChecker.cpp
-  InnerPointerChecker.cpp
-  IteratorChecker.cpp
-  IvarInvalidationChecker.cpp
-  LLVMConventionsChecker.cpp
-  LocalizationChecker.cpp
-  MacOSKeychainAPIChecker.cpp
-  MacOSXAPIChecker.cpp
-  MallocChecker.cpp
-  MallocOverflowSecurityChecker.cpp
-  MallocSizeofChecker.cpp
-  MmapWriteExecChecker.cpp
-  MoveChecker.cpp
-  MPI-Checker/MPIBugReporter.cpp
-  MPI-Checker/MPIChecker.cpp
-  MPI-Checker/MPIFunctionClassifier.cpp
-  NSAutoreleasePoolChecker.cpp
-  NSErrorChecker.cpp
-  NoReturnFunctionChecker.cpp
-  NonNullParamChecker.cpp
-  NonnullGlobalConstantsChecker.cpp
-  NullabilityChecker.cpp
-  NumberObjectConversionChecker.cpp
-  ObjCAtSyncChecker.cpp
-  ObjCAutoreleaseWriteChecker.cpp
-  ObjCContainersASTChecker.cpp
-  ObjCContainersChecker.cpp
-  ObjCMissingSuperCallChecker.cpp
-  ObjCPropertyChecker.cpp
-  ObjCSelfInitChecker.cpp
-  ObjCSuperDeallocChecker.cpp
-  ObjCUnusedIVarsChecker.cpp
-  PaddingChecker.cpp
-  PointerArithChecker.cpp
-  PointerSubChecker.cpp
-  PthreadLockChecker.cpp
-  RetainCountChecker/RetainCountChecker.cpp
-  RetainCountChecker/RetainCountDiagnostics.cpp
-  ReturnPointerRangeChecker.cpp
-  ReturnUndefChecker.cpp
-  RunLoopAutoreleaseLeakChecker.cpp
-  SimpleStreamChecker.cpp
-  StackAddrEscapeChecker.cpp
-  StdLibraryFunctionsChecker.cpp
-  StreamChecker.cpp
-  TaintTesterChecker.cpp
-  TestAfterDivZeroChecker.cpp
-  TraversalChecker.cpp
-  TrustNonnullChecker.cpp
-  UndefBranchChecker.cpp
-  UndefCapturedBlockVarChecker.cpp
-  UndefResultChecker.cpp
-  UndefinedArraySubscriptChecker.cpp
-  UndefinedAssignmentChecker.cpp
-  UninitializedObject/UninitializedObjectChecker.cpp
-  UninitializedObject/UninitializedPointee.cpp
-  UnixAPIChecker.cpp
-  UnreachableCodeChecker.cpp
-  VforkChecker.cpp
-  VLASizeChecker.cpp
-  ValistChecker.cpp
-  VirtualCallChecker.cpp
-
-  LINK_LIBS
-  clangAST
-  clangASTMatchers
-  clangAnalysis
-  clangBasic
-  clangLex
-  clangStaticAnalyzerCore
-  )
diff --git a/lib/StaticAnalyzer/Core/CMakeLists.txt b/lib/StaticAnalyzer/Core/CMakeLists.txt
deleted file mode 100644
index 167f78af6289..000000000000
--- a/lib/StaticAnalyzer/Core/CMakeLists.txt
+++ /dev/null
@@ -1,75 +0,0 @@
-set(LLVM_LINK_COMPONENTS support)
-
-# Link Z3 if the user wants to build it.
-if(CLANG_ANALYZER_WITH_Z3)
-  set(Z3_LINK_FILES ${Z3_LIBRARIES})
-else()
-  set(Z3_LINK_FILES "")
-endif()
-
-add_clang_library(clangStaticAnalyzerCore
-  APSIntType.cpp
-  AnalysisManager.cpp
-  AnalyzerOptions.cpp
-  BasicValueFactory.cpp
-  BlockCounter.cpp
-  BugReporter.cpp
-  BugReporterVisitors.cpp
-  CallEvent.cpp
-  Checker.cpp
-  CheckerContext.cpp
-  CheckerHelpers.cpp
-  CheckerManager.cpp
-  CommonBugCategories.cpp
-  ConstraintManager.cpp
-  CoreEngine.cpp
-  DynamicTypeMap.cpp
-  Environment.cpp
-  ExplodedGraph.cpp
-  ExprEngine.cpp
-  ExprEngineC.cpp
-  ExprEngineCXX.cpp
-  ExprEngineCallAndReturn.cpp
-  ExprEngineObjC.cpp
-  FunctionSummary.cpp
-  HTMLDiagnostics.cpp
-  IssueHash.cpp
-  LoopUnrolling.cpp
-  LoopWidening.cpp
-  MemRegion.cpp
-  PathDiagnostic.cpp
-  PlistDiagnostics.cpp
-  ProgramState.cpp
-  RangeConstraintManager.cpp
-  RangedConstraintManager.cpp
-  RegionStore.cpp
-  RetainSummaryManager.cpp
-  SarifDiagnostics.cpp
-  SimpleConstraintManager.cpp
-  SimpleSValBuilder.cpp
-  Store.cpp
-  SubEngine.cpp
-  SValBuilder.cpp
-  SVals.cpp
-  SymbolManager.cpp
-  TaintManager.cpp
-  WorkList.cpp
-  Z3ConstraintManager.cpp
-
-  LINK_LIBS
-  clangAST
-  clangASTMatchers
-  clangAnalysis
-  clangBasic
-  clangCrossTU
-  clangLex
-  clangRewrite
-  ${Z3_LINK_FILES}
-  )
-
-if(CLANG_ANALYZER_WITH_Z3)
-  target_include_directories(clangStaticAnalyzerCore SYSTEM
-    PRIVATE
-    ${Z3_INCLUDE_DIR}
-    )
-endif()
diff --git a/lib/StaticAnalyzer/Frontend/CMakeLists.txt b/lib/StaticAnalyzer/Frontend/CMakeLists.txt
deleted file mode 100644
index 5e7dd8f18cd7..000000000000
--- a/lib/StaticAnalyzer/Frontend/CMakeLists.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-include_directories( ${CMAKE_CURRENT_BINARY_DIR}/../Checkers )
-
-set(LLVM_LINK_COMPONENTS
-  Support
-  )
-
-add_clang_library(clangStaticAnalyzerFrontend
-  AnalysisConsumer.cpp
-  CheckerRegistration.cpp
-  CheckerRegistry.cpp
-  FrontendActions.cpp
-  ModelConsumer.cpp
-  ModelInjector.cpp
-
-  LINK_LIBS
-  clangAST
-  clangAnalysis
-  clangBasic
-  clangCrossTU
-  clangFrontend
-  clangLex
-  clangStaticAnalyzerCheckers
-  clangStaticAnalyzerCore
-  )
diff --git a/lib/StaticAnalyzer/README.txt b/lib/StaticAnalyzer/README.txt
deleted file mode 100644
index 79a16ec7673d..000000000000
--- a/lib/StaticAnalyzer/README.txt
+++ /dev/null
@@ -1,139 +0,0 @@
-//===----------------------------------------------------------------------===//
-// Clang Static Analyzer
-//===----------------------------------------------------------------------===//
-
-= Library Structure =
-
-The analyzer library has two layers: a (low-level) static analysis
-engine (GRExprEngine.cpp and friends), and some static checkers
-(*Checker.cpp).  The latter are built on top of the former via the
-Checker and CheckerVisitor interfaces (Checker.h and
-CheckerVisitor.h).  The Checker interface is designed to be minimal
-and simple for checker writers, and attempts to isolate them from much
-of the gore of the internal analysis engine.
-
-= How It Works =
-
-The analyzer is inspired by several foundational research papers ([1],
-[2]).  (FIXME: kremenek to add more links)
-
-In a nutshell, the analyzer is basically a source code simulator that
-traces out possible paths of execution.  The state of the program
-(values of variables and expressions) is encapsulated by the state
-(ProgramState).  A location in the program is called a program point
-(ProgramPoint), and the combination of state and program point is a
-node in an exploded graph (ExplodedGraph).  The term "exploded" comes
-from exploding the control-flow edges in the control-flow graph (CFG).
-
-Conceptually the analyzer does a reachability analysis through the
-ExplodedGraph.  We start at a root node, which has the entry program
-point and initial state, and then simulate transitions by analyzing
-individual expressions.  The analysis of an expression can cause the
-state to change, resulting in a new node in the ExplodedGraph with an
-updated program point and an updated state.  A bug is found by hitting
-a node that satisfies some "bug condition" (basically a violation of a
-checking invariant).
-
-The analyzer traces out multiple paths by reasoning about branches and
-then bifurcating the state: on the true branch the conditions of the
-branch are assumed to be true and on the false branch the conditions
-of the branch are assumed to be false.  Such "assumptions" create
-constraints on the values of the program, and those constraints are
-recorded in the ProgramState object (and are manipulated by the
-ConstraintManager).  If assuming the conditions of a branch would
-cause the constraints to be unsatisfiable, the branch is considered
-infeasible and that path is not taken.  This is how we get
-path-sensitivity.  We reduce exponential blow-up by caching nodes.  If
-a new node with the same state and program point as an existing node
-would get generated, the path "caches out" and we simply reuse the
-existing node.  Thus the ExplodedGraph is not a DAG; it can contain
-cycles as paths loop back onto each other and cache out.
-
-ProgramState and ExplodedNodes are basically immutable once created.  Once
-one creates a ProgramState, you need to create a new one to get a new
-ProgramState.  This immutability is key since the ExplodedGraph represents
-the behavior of the analyzed program from the entry point.  To
-represent these efficiently, we use functional data structures (e.g.,
-ImmutableMaps) which share data between instances.
-
-Finally, individual Checkers work by also manipulating the analysis
-state.  The analyzer engine talks to them via a visitor interface.
-For example, the PreVisitCallExpr() method is called by GRExprEngine
-to tell the Checker that we are about to analyze a CallExpr, and the
-checker is asked to check for any preconditions that might not be
-satisfied.  The checker can do nothing, or it can generate a new
-ProgramState and ExplodedNode which contains updated checker state.  If it
-finds a bug, it can tell the BugReporter object about the bug,
-providing it an ExplodedNode which is the last node in the path that
-triggered the problem.
-
-= Notes about C++ =
-
-Since now constructors are seen before the variable that is constructed
-in the CFG, we create a temporary object as the destination region that
-is constructed into. See ExprEngine::VisitCXXConstructExpr().
-
-In ExprEngine::processCallExit(), we always bind the object region to the
-evaluated CXXConstructExpr. Then in VisitDeclStmt(), we compute the
-corresponding lazy compound value if the variable is not a reference, and
-bind the variable region to the lazy compound value. If the variable
-is a reference, just use the object region as the initializer value.
-
-Before entering a C++ method (or ctor/dtor), the 'this' region is bound
-to the object region. In ctors, we synthesize 'this' region with
-CXXRecordDecl*, which means we do not use type qualifiers. In methods, we
-synthesize 'this' region with CXXMethodDecl*, which has getThisType()
-taking type qualifiers into account. It does not matter we use qualified
-'this' region in one method and unqualified 'this' region in another
-method, because we only need to ensure the 'this' region is consistent
-when we synthesize it and create it directly from CXXThisExpr in a single
-method call.
-
-= Working on the Analyzer =
-
-If you are interested in bringing up support for C++ expressions, the
-best place to look is the visitation logic in GRExprEngine, which
-handles the simulation of individual expressions.  There are plenty of
-examples there of how other expressions are handled.
-
-If you are interested in writing checkers, look at the Checker and
-CheckerVisitor interfaces (Checker.h and CheckerVisitor.h).  Also look
-at the files named *Checker.cpp for examples on how you can implement
-these interfaces.
-
-= Debugging the Analyzer =
-
-There are some useful command-line options for debugging.  For example:
-
-$ clang -cc1 -help | grep analyze
- -analyze-function <value>
- -analyzer-display-progress
- -analyzer-viz-egraph-graphviz
- ...
-
-The first allows you to specify only analyzing a specific function.
-The second prints to the console what function is being analyzed.  The
-third generates a graphviz dot file of the ExplodedGraph.  This is
-extremely useful when debugging the analyzer and viewing the
-simulation results.
-
-Of course, viewing the CFG (Control-Flow Graph) is also useful:
-
-$ clang -cc1 -help | grep cfg
- -cfg-add-implicit-dtors Add C++ implicit destructors to CFGs for all analyses
- -cfg-add-initializers   Add C++ initializers to CFGs for all analyses
- -cfg-dump               Display Control-Flow Graphs
- -cfg-view               View Control-Flow Graphs using GraphViz
- -unoptimized-cfg        Generate unoptimized CFGs for all analyses
-
--cfg-dump dumps a textual representation of the CFG to the console,
-and -cfg-view creates a GraphViz representation.
-
-= References =
-
-[1] Precise interprocedural dataflow analysis via graph reachability,
-    T Reps, S Horwitz, and M Sagiv, POPL '95,
-    http://portal.acm.org/citation.cfm?id=199462
-
-[2] A memory model for static analysis of C programs, Z Xu, T
-    Kremenek, and J Zhang, http://lcs.ios.ac.cn/~xzx/memmodel.pdf