a4de17562d13d7a8188108243c4cfbd52f33229a |
|
04-Mar-2016 |
Pirama Arumuga Nainar <pirama@google.com> |
Update aosp/master clang for rebase to r256229 http://b/26987366 (cherry picked from commit 87d948ecccffea9e9e37d0d053b246e2d6d6c47b) Change-Id: I10ca401a280e905253aafabad9118693a2f24ffb
/external/clang/lib/AST/ParentMap.cpp
|
6bcf27bb9a4b5c3f79cb44c0e4654a6d7619ad89 |
|
29-May-2014 |
Stephen Hines <srhines@google.com> |
Update Clang for 3.5 rebase (r209713). Change-Id: I8c9133b0f8f776dc915f270b60f94962e771bc83
/external/clang/lib/AST/ParentMap.cpp
|
49a246f4fad959888bb0164c624c3c2b03078e91 |
|
06-Jun-2013 |
Jordan Rose <jordan_rose@apple.com> |
[analyzer; new edges] Simplify edges in a C++11 for-range loop. Previously our edges were completely broken here; now, the final result is a very simple set of edges in most cases: one up to the "for" keyword for context, and one into the body of the loop. This matches the behavior for ObjC for-in loops. In the AST, however, CXXForRangeStmts are handled very differently from ObjCForCollectionStmts. Since they are specified in terms of equivalent statements in the C++ standard, we actually have implicit AST nodes for all of the semantic statements. This makes evaluation very easy, but diagnostic locations a bit trickier. Fortunately, the problem can be generally defined away by marking all of the implicit statements as part of the top-level for-range statement. One of the implicit statements in a for-range statement is the declaration of implicit iterators __begin and __end. The CFG synthesizes two separate DeclStmts to match each of these decls, but until now these synthetic DeclStmts weren't in the function's ParentMap. Now, the CFG keeps track of its synthetic statements, and the AnalysisDeclContext will make sure to add them to the ParentMap. <rdar://problem/14038483> git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@183449 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/AST/ParentMap.cpp
|
fb6f75feaa0fa6621282df1075677a26fdfde1b7 |
|
06-Jun-2013 |
Jordan Rose <jordan_rose@apple.com> |
[analyzer] Look through ExprWithCleanups to see if an expr's consumed. We based decisions during analysis and during path generation on whether or not an expression is consumed, so if a top-level expression has cleanups it's important for us to look through that. <rdar://problem/14076125> git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@183368 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/AST/ParentMap.cpp
|
fa047c580506041d1120023b10c6a3528c8016c6 |
|
18-May-2013 |
Serge Pavlov <sepavloff@gmail.com> |
Removed invalid character. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182189 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/AST/ParentMap.cpp
|
b9fdfb50983012b3460e3c27737ec8cdfdb8627d |
|
18-May-2013 |
Jordan Rose <jordan_rose@apple.com> |
[analyzer] "Fix" ParentMap to handle non-syntactic OpaqueValueExprs. Constructs like PseudoObjectExpr, where an expression can appear more than once in the AST, use OpaqueValueExprs to guard against inadvertent re-processing of the shared expression during AST traversal. The most common form of this is to share expressions between the syntactic "as-written" form of, say, an Objective-C property access 'obj.prop', and the underlying "semantic" form '[obj prop]'. However, some constructs can produce OpaqueValueExprs that don't appear in the syntactic form at all; in these cases the ParentMap wasn't ever traversing the children of these expressions. This patch fixes that by checking to see if an OpaqueValueExpr's child has ever been traversed before. There's also a bit of reset logic when visiting a PseudoObjectExpr to handle the case of updating the ParentMap, which some external clients depend on. This still isn't exactly the right fix because we probably want the parent of the OpaqueValueExpr itself to be its location in the syntactic form if it's syntactic and the PseudoObjectExpr or BinaryConditionalOperator itself if it's semantic. Whe I originally wrote the code to do this, I didn't realize that OpaqueValueExprs themselves are shared in the AST, not just their source expressions. This patch doesn't change the existing behavior so as not to break anything inadvertently relying on it; we'll come back to this later. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182187 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/AST/ParentMap.cpp
|
bb518991ce4298d8662235fc8cb13813f011c18d |
|
18-May-2013 |
Jordan Rose <jordan_rose@apple.com> |
Revert "[analyzer; alternate edges] improve support for edges with PseudoObjectExprs." Ted and I spent a long time discussing this today and found out that neither the existing code nor the new code was doing what either of us thought it was, which is never good. The good news is we found a much simpler way to fix the motivating test case (an ObjCSubscriptExpr). This reverts r182083, but pieces of it will come back in subsequent commits. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182185 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/AST/ParentMap.cpp
|
e9aae62e8bca3abfc1dc36f67845444291171e13 |
|
17-May-2013 |
Ted Kremenek <kremenek@apple.com> |
[analyzer; alternate edges] improve support for edges with PseudoObjectExprs. This optimizes some spurious edges resulting from PseudoObjectExprs. This required far more changes than I anticipated. The current ParentMap does not record any hierarchy information between a PseudoObjectExpr and its *semantic* expressions that may be wrapped in OpaqueValueExprs, which are the expressions actually laid out in the CFG. This means the arrow pruning logic could not map from an expression to its containing PseudoObjectExprs. To solve this, this patch adds a variant of ParentMap that returns the "semantic" parentage of expressions (essentially as they are viewed by the CFG). This alternate ParentMap is then used by the arrow reducing logic to identify edges into pseudo object expressions, and then eliminate them. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182083 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/AST/ParentMap.cpp
|
1e5101e1e52729564b6fc8d7bf146cef33bc31ca |
|
06-Oct-2012 |
Jordan Rose <jordan_rose@apple.com> |
ParentMap: Restore the ability to update an existing map. The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to choose a single parent for each object. In the main (only?) cases in which the AST forms a DAG, it protects from multiple traversal by using OpaqueValueExprs. Previously, ParentMap would just unconditionally look through all OpaqueValueExprs when building its map. In order to make this behavior better for the analyzer's diagnostics, ParentMap was changed to not set a statement's parent if there already was one in the map. However, ParentMap is supposed to allow updating existing mappings by calling addStmt once again. This change makes the "transparency" of OpaqueValueExprs explicit, and disables it when it is not desired, rather than checking the current contents of the map. This new code seems like a big change, but it should actually have essentially the same performance as before. Only OpaqueValueExprs and their users (PseudoObjectExpr and BinaryConditionalOperator) will have any different behavior. There should be no user-visible functionality change, though a test has been added for the current behavior of BinaryConditionalOperator source locations and accompanying Xcode arrows (which are not so great...). git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165355 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/AST/ParentMap.cpp
|
2b1b025fa6e848ec36c0554924d7d63342aa80e4 |
|
06-Aug-2012 |
Jordan Rose <jordan_rose@apple.com> |
[analyzer] Improve arrow locations for PseudoObjectExprs. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161350 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/AST/ParentMap.cpp
|
e215ba1c2a3f29fe2cbc4cfb0e532cd204970c49 |
|
18-Feb-2012 |
Ted Kremenek <kremenek@apple.com> |
Fix crash in analyzer diagnostic generation involving subexpressions of OpaqueValueExpr not appearing in the ParentMap. Fixes <rdar://problem/10797980>. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150894 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/AST/ParentMap.cpp
|
18fd0c6915b45c4daafe18e3cd324c13306f913f |
|
27-Jul-2011 |
Argyrios Kyrtzidis <akyrtzi@gmail.com> |
[arcmt] More automatic transformations and safety improvements; rdar://9615812 : - Replace calling -zone with 'nil'. -zone is obsolete in ARC. - Allow removing retain/release on a static global var. - Fix assertion hit when scanning for name references outside a NSAutoreleasePool scope. - Automatically add bridged casts for results of objc method calls and when calling CFRetain, for example: NSString *s; CFStringRef ref = [s string]; -> CFStringRef ref = (__bridge CFStringRef)([s string]); ref = s.string; -> ref = (__bridge CFStringRef)(s.string); ref = [NSString new]; -> ref = (__bridge_retained CFStringRef)([NSString new]); ref = [s newString]; -> ref = (__bridge_retained CFStringRef)([s newString]); ref = [[NSString alloc] init]; -> ref = (__bridge_retained CFStringRef)([[NSString alloc] init]); ref = [[s string] retain]; -> ref = (__bridge_retained CFStringRef)([s string]); ref = CFRetain(s); -> ref = (__bridge_retained CFTypeRef)(s); ref = [s retain]; -> ref = (__bridge_retained CFStringRef)(s); - Emit migrator error when trying to cast to CF type the result of autorelease/release: for CFStringRef f3() { return (CFStringRef)[[[NSString alloc] init] autorelease]; } emits: t.m:12:10: error: [rewriter] it is not safe to cast to 'CFStringRef' the result of 'autorelease' message; a __bridge cast may result in a pointer to a destroyed object and a __bridge_retained may leak the object return (CFStringRef)[[[NSString alloc] init] autorelease]; ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ t.m:12:3: note: [rewriter] remove the cast and change return type of function to 'NSString *' to have the object automatically autoreleased return (CFStringRef)[[[NSString alloc] init] autorelease]; ^ - Before changing attributes to weak/unsafe_unretained, check if the backing ivar is set to a +1 object, in which case use 'strong' instead. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@136208 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/AST/ParentMap.cpp
|
f85e193739c953358c865005855253af4f68a497 |
|
16-Jun-2011 |
John McCall <rjmccall@apple.com> |
Automatic Reference Counting. Language-design credit goes to a lot of people, but I particularly want to single out Blaine Garst and Patrick Beard for their contributions. Compiler implementation credit goes to Argyrios, Doug, Fariborz, and myself, in no particular order. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133103 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/AST/ParentMap.cpp
|
7502c1d3ce8bb97bcc4f7bebef507040bd93b26f |
|
13-Feb-2011 |
John McCall <rjmccall@apple.com> |
Give some convenient idiomatic accessors to Stmt::child_range and Stmt::const_child_range, then make a bunch of places use them instead of the individual iterator accessors. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@125450 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/AST/ParentMap.cpp
|
f4e532b5a1683a9f6c842f361c7415bf3474315f |
|
12-Feb-2011 |
Ted Kremenek <kremenek@apple.com> |
Don't emit a dead store for '++' operations unless it occurs with a return statement. We've never seen any other cases that were real bugs. Fixes <rdar://problem/6962292>. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@125419 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/AST/ParentMap.cpp
|
d6543f8bbac18cdb678a67da2a676c30c2941eca |
|
15-Nov-2010 |
Ted Kremenek <kremenek@apple.com> |
Add method ParentMap::addStmt(). git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@119181 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/AST/ParentMap.cpp
|
2de56d1d0c3a504ad1529de2677628bdfbb95cd4 |
|
25-Aug-2010 |
John McCall <rjmccall@apple.com> |
GCC didn't care for my attempt at API compatibility, so brute-force everything to the new constants. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112047 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/AST/ParentMap.cpp
|
1eb4433ac451dc16f4133a88af2d002ac26c58ef |
|
09-Sep-2009 |
Mike Stump <mrs@apple.com> |
Remove tabs, and whitespace cleanups. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@81346 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/AST/ParentMap.cpp
|
b1b9f680f5fc65230de877baccae50820a969a94 |
|
11-May-2009 |
Ted Kremenek <kremenek@apple.com> |
Add ParentMap:getParentIgnoreParens(). git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71469 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/AST/ParentMap.cpp
|
ade9ecaba935489840fa74aaf5b4c640d6589e33 |
|
06-May-2009 |
Ted Kremenek <kremenek@apple.com> |
Fix subtle bug in ParentMap::isConsumedExpr(): correctly ignore *parents* that are ParenExpr or CastExprs. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71026 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/AST/ParentMap.cpp
|
24ae89a5a25f8971c7436bb3b7663e66ed99b987 |
|
09-Apr-2009 |
Ted Kremenek <kremenek@apple.com> |
Another ParentMap bug: only the right side of a comma expression is consumed. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@68680 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/AST/ParentMap.cpp
|
e42ac98bc2d50506216b6ef258594bdaa59c47c1 |
|
08-Apr-2009 |
Ted Kremenek <kremenek@apple.com> |
Fix bug in ParentMap::isConsumedExpr. A BinaryOperator always "consumes" the value of its subexpressions unless it is a comma (in which case it doesn't consume the left subexpression). git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@68628 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/AST/ParentMap.cpp
|
b930d7adb7cb7642c9c49b39df04ebd5cbfa713a |
|
01-Apr-2009 |
Ted Kremenek <kremenek@apple.com> |
Fix: <rdar://problem/6740387>. Sending nil to an object that returns a struct should only be an error if that value is consumed. This fix was largely accomplished by moving 'isConsumedExpr' back to ParentMap. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@68195 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/AST/ParentMap.cpp
|
7f5fce7200fdbf03f7d70134a57271e584fcb766 |
|
20-Jan-2009 |
Ted Kremenek <kremenek@apple.com> |
Dead stores checker: Fix <rdar://problem/6506065> by being more selective when say that a store is dead even though the computed value is used in the enclosing expression. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@62552 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/AST/ParentMap.cpp
|
acc5f3e42334525bf28c86471551f83dfce222d5 |
|
11-Aug-2008 |
Daniel Dunbar <daniel@zuster.org> |
More #include cleaning - Kill unnecessary #includes in .cpp files. This is an automatic sweep so some things removed are actually used, but happen to be included by a previous header. I tried to get rid of the obvious examples and this was the easiest way to trim the #includes in one fell swoop. - We now return to regularly scheduled development. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@54632 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/AST/ParentMap.cpp
|
f8e32cf062f39fff1a00aff748cb6b5dc0abc2fe |
|
20-Jun-2008 |
Ted Kremenek <kremenek@apple.com> |
Added ParentMap, a class to represent a lazily constructed mapping from child to parents. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@52553 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/AST/ParentMap.cpp
|