[PATCH] D17968: [analyzer] Remove GR prefix in docs and comments.

[don hinton via cfe-commits]

hintonda created this revision.
hintonda added a reviewer: krememek.
hintonda added a subscriber: cfe-commits.

The GR prefix was removed form file and class names, so make
docs and comments match.  Also, fix a few minor typos.

http://reviews.llvm.org/D17968

Files:
  lib/StaticAnalyzer/README.txt
  test/Analysis/PR3991.m
  test/Analysis/misc-ps-eager-assume.m

Index: test/Analysis/misc-ps-eager-assume.m
===================================================================
--- test/Analysis/misc-ps-eager-assume.m
+++ test/Analysis/misc-ps-eager-assume.m
@@ -49,7 +49,7 @@
 // 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,12 +128,12 @@
 //  This test case depends on using -analyzer-eagerly-assume and
 //  -analyzer-store=region.  The '-analyzer-eagerly-assume' 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.
 //  Note: CheckerVisit mistakenly cleared an existing node, and the cleared
-//  node was resurrected by GRStmtNodeBuilder::~GRStmtNodeBuilder(), where
+//  node was resurrected by StmtNodeBuilder::~StmtNodeBuilder(), where
 //  'p' was not assigned.
 //===---------------------------------------------------------------------===//
 
Index: test/Analysis/PR3991.m
===================================================================
--- test/Analysis/PR3991.m
+++ test/Analysis/PR3991.m
@@ -50,7 +50,7 @@
 // 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.
 //===----------------------------------------------------------------------===//
 
Index: lib/StaticAnalyzer/README.txt
===================================================================
--- lib/StaticAnalyzer/README.txt
+++ 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 @@
 
 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
@@ -69,7 +69,7 @@
 
 = Notes about C++ =
 
-Since now constructors are seen before the variable that is constructed 
+Since 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().
 
@@ -83,16 +83,16 @@
 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
+taking type qualifiers into account. It does not matter if we use a qualified
+'this' region in one method and an 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
+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.
 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: D17968.50068.patch
Type: text/x-patch
Size: 4638 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20160308/cf3d49aa/attachment.bin>