[analyzer][NFC] Rename GREngine->CoreEngine, GRExprEngine->ExprEngine in comments and txt files

fixes #115

clang/lib/StaticAnalyzer/Core/ExprEngine.cpp

@@ -7,7 +7,7 @@
 //===----------------------------------------------------------------------===//
 //
 //  This file defines a meta-engine for path-sensitive dataflow analysis that
-//  is built on GREngine, but provides the boilerplate to execute transfer
+//  is built on CoreEngine, but provides the boilerplate to execute transfer
 //  functions and build the ExplodedGraph at the expression level.
 //
 //===----------------------------------------------------------------------===//

clang/lib/StaticAnalyzer/README.txt

@@ -5,7 +5,7 @@
 = Library Structure =
 
 The analyzer library has two layers: a (low-level) static analysis
-engine (GRExprEngine.cpp and friends), and some static checkers
+engine (ExprEngine.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
@@ -58,7 +58,7 @@ 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
+For example, the PreVisitCallExpr() method is called by ExprEngine
 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
@@ -92,7 +92,7 @@ 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
+best place to look is the visitation logic in ExprEngine, which
 handles the simulation of individual expressions.  There are plenty of
 examples there of how other expressions are handled.
 

clang/test/Analysis/PR3991.m

@@ -50,7 +50,7 @@ typedef struct _NSZone NSZone;
 // Actual test case:
 //
 // The analyzer currently doesn't reason about ObjCKVCRefExpr.  Have both
-// GRExprEngine::Visit and GRExprEngine::VisitLValue have such expressions
+// ExprEngine::Visit and ExprEngine::VisitLValue have such expressions
 // evaluate to UnknownVal.
 //===----------------------------------------------------------------------===//
 

clang/test/Analysis/misc-ps-eager-assume.m

@@ -49,7 +49,7 @@ void handle_assign_of_condition(int x) {
 // a symbolic value for this variable, but in the branch condition it is
 // promoted to 'int'.  Currently the analyzer doesn't reason well about
 // promotions of symbolic values, so this test case tests the logic in
-// 'recoverCastedSymbol()' (GRExprEngine.cpp) to test that we recover
+// 'recoverCastedSymbol()' (ExprEngine.cpp) to test that we recover
 // path-sensitivity and use the symbol for 'needsAnArray' in the branch
 // condition.
 //
@@ -128,7 +128,7 @@ void rdar7342806(void) {
 //  This test case depends on using -analyzer-config eagerly-assume=true and
 //  -analyzer-store=region.  The 'eagerly-assume=true' causes the path
 //  to bifurcate when evaluating the function call argument, and a state
-//  caching bug in GRExprEngine::CheckerVisit (and friends) caused the store
+//  caching bug in ExprEngine::CheckerVisit (and friends) caused the store
 //  to 'p' to not be evaluated along one path, but then an autotransition caused
 //  the path to keep on propagating with 'p' still set to an undefined value.
 //  We would then get a bogus report of returning uninitialized memory.