pghs975uc
/
infer_clone
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '9b5820bf32'
${ noResults }
infer_clone/infer/tests/codetoanalyze/objc/shared/block/block_release.m.dot

91 lines
8.3 KiB
Raw Normal View History Unescape

Add @generated comment to icfg.dot files Reviewed By: jvillard Differential Revision: D3358243 fbshipit-source-id: a47cc01
9 years ago
/* @generated */
[cfg] rename iCFG to cfg in dotty files Summary: Not sure what an "iCFG" is but the dotty is only about CFGs anyway. Diff obtained by mass-`sed`. Reviewed By: sblackshear Differential Revision: D6324280 fbshipit-source-id: b7603bb
7 years ago
digraph cfg {
[IR] Fix the function hashable_name for ObjC methods Summary: This function had been computing the name for ObjC methods wrong, with only the class name. This was causing wrong error messages in Pulse. The main issue was that `Procname.to_simplified_string` was writing `Classname::methodname` for ObjC methods, which is not the convention. This confused the `hashable_name` funtion. So changing the method name to `Classname.methodname` which is more standard, and this also fixes `hashable_name`. Reviewed By: ngorogiannis, jvillard Differential Revision: D21570880 fbshipit-source-id: 13ed62cf8
5 years ago
"objc_blockMy_manager.blockReleaseNoLeak_1(struct CGImage).d2039f8bbb0530575d5ff258d059d268_1" [label="1: Start objc_blockMy_manager.blockReleaseNoLeak_1\nFormals: newImage:CGImage* a:int\nLocals: \nCaptured: newImage:CGImage* \n " color=yellow style=filled]
[debug] print procedures in alphabetical order in cfgs Summary: When looking at large CFGs, at least in `xdot`, it's often difficult to find the procedure you're looking for. Sorting the proc names puts them in alphabetical order, which makes searching one procedure easier. Reviewed By: mbouaziz Differential Revision: D7758521 fbshipit-source-id: 8e9997f
7 years ago
[IR] Fix the function hashable_name for ObjC methods Summary: This function had been computing the name for ObjC methods wrong, with only the class name. This was causing wrong error messages in Pulse. The main issue was that `Procname.to_simplified_string` was writing `Classname::methodname` for ObjC methods, which is not the convention. This confused the `hashable_name` funtion. So changing the method name to `Classname.methodname` which is more standard, and this also fixes `hashable_name`. Reviewed By: ngorogiannis, jvillard Differential Revision: D21570880 fbshipit-source-id: 13ed62cf8
5 years ago
"objc_blockMy_manager.blockReleaseNoLeak_1(struct CGImage).d2039f8bbb0530575d5ff258d059d268_1" -> "objc_blockMy_manager.blockReleaseNoLeak_1(struct CGImage).d2039f8bbb0530575d5ff258d059d268_5" ;
"objc_blockMy_manager.blockReleaseNoLeak_1(struct CGImage).d2039f8bbb0530575d5ff258d059d268_1" -> "objc_blockMy_manager.blockReleaseNoLeak_1(struct CGImage).d2039f8bbb0530575d5ff258d059d268_6" ;
"objc_blockMy_manager.blockReleaseNoLeak_1(struct CGImage).d2039f8bbb0530575d5ff258d059d268_2" [label="2: Exit objc_blockMy_manager.blockReleaseNoLeak_1 \n " color=yellow style=filled]
[debug] print procedures in alphabetical order in cfgs Summary: When looking at large CFGs, at least in `xdot`, it's often difficult to find the procedure you're looking for. Sorting the proc names puts them in alphabetical order, which makes searching one procedure easier. Reviewed By: mbouaziz Differential Revision: D7758521 fbshipit-source-id: 8e9997f
7 years ago
[IR] Fix the function hashable_name for ObjC methods Summary: This function had been computing the name for ObjC methods wrong, with only the class name. This was causing wrong error messages in Pulse. The main issue was that `Procname.to_simplified_string` was writing `Classname::methodname` for ObjC methods, which is not the convention. This confused the `hashable_name` funtion. So changing the method name to `Classname.methodname` which is more standard, and this also fixes `hashable_name`. Reviewed By: ngorogiannis, jvillard Differential Revision: D21570880 fbshipit-source-id: 13ed62cf8
5 years ago
"objc_blockMy_manager.blockReleaseNoLeak_1(struct CGImage).d2039f8bbb0530575d5ff258d059d268_3" [label="3: + \n " ]
[debug] print procedures in alphabetical order in cfgs Summary: When looking at large CFGs, at least in `xdot`, it's often difficult to find the procedure you're looking for. Sorting the proc names puts them in alphabetical order, which makes searching one procedure easier. Reviewed By: mbouaziz Differential Revision: D7758521 fbshipit-source-id: 8e9997f
7 years ago
[IR] Fix the function hashable_name for ObjC methods Summary: This function had been computing the name for ObjC methods wrong, with only the class name. This was causing wrong error messages in Pulse. The main issue was that `Procname.to_simplified_string` was writing `Classname::methodname` for ObjC methods, which is not the convention. This confused the `hashable_name` funtion. So changing the method name to `Classname.methodname` which is more standard, and this also fixes `hashable_name`. Reviewed By: ngorogiannis, jvillard Differential Revision: D21570880 fbshipit-source-id: 13ed62cf8
5 years ago
"objc_blockMy_manager.blockReleaseNoLeak_1(struct CGImage).d2039f8bbb0530575d5ff258d059d268_3" -> "objc_blockMy_manager.blockReleaseNoLeak_1(struct CGImage).d2039f8bbb0530575d5ff258d059d268_4" ;
"objc_blockMy_manager.blockReleaseNoLeak_1(struct CGImage).d2039f8bbb0530575d5ff258d059d268_4" [label="4: between_join_and_exit \n " shape="box"]
[debug] print procedures in alphabetical order in cfgs Summary: When looking at large CFGs, at least in `xdot`, it's often difficult to find the procedure you're looking for. Sorting the proc names puts them in alphabetical order, which makes searching one procedure easier. Reviewed By: mbouaziz Differential Revision: D7758521 fbshipit-source-id: 8e9997f
7 years ago
[IR] Fix the function hashable_name for ObjC methods Summary: This function had been computing the name for ObjC methods wrong, with only the class name. This was causing wrong error messages in Pulse. The main issue was that `Procname.to_simplified_string` was writing `Classname::methodname` for ObjC methods, which is not the convention. This confused the `hashable_name` funtion. So changing the method name to `Classname.methodname` which is more standard, and this also fixes `hashable_name`. Reviewed By: ngorogiannis, jvillard Differential Revision: D21570880 fbshipit-source-id: 13ed62cf8
5 years ago
"objc_blockMy_manager.blockReleaseNoLeak_1(struct CGImage).d2039f8bbb0530575d5ff258d059d268_4" -> "objc_blockMy_manager.blockReleaseNoLeak_1(struct CGImage).d2039f8bbb0530575d5ff258d059d268_2" ;
"objc_blockMy_manager.blockReleaseNoLeak_1(struct CGImage).d2039f8bbb0530575d5ff258d059d268_5" [label="5: Prune (true branch, if) \n n$10=*&newImage:CGImage* [line 24, column 9]\n PRUNE(n$10, true); [line 24, column 9]\n " shape="invhouse"]
[debug] print procedures in alphabetical order in cfgs Summary: When looking at large CFGs, at least in `xdot`, it's often difficult to find the procedure you're looking for. Sorting the proc names puts them in alphabetical order, which makes searching one procedure easier. Reviewed By: mbouaziz Differential Revision: D7758521 fbshipit-source-id: 8e9997f
7 years ago
[IR] Fix the function hashable_name for ObjC methods Summary: This function had been computing the name for ObjC methods wrong, with only the class name. This was causing wrong error messages in Pulse. The main issue was that `Procname.to_simplified_string` was writing `Classname::methodname` for ObjC methods, which is not the convention. This confused the `hashable_name` funtion. So changing the method name to `Classname.methodname` which is more standard, and this also fixes `hashable_name`. Reviewed By: ngorogiannis, jvillard Differential Revision: D21570880 fbshipit-source-id: 13ed62cf8
5 years ago
"objc_blockMy_manager.blockReleaseNoLeak_1(struct CGImage).d2039f8bbb0530575d5ff258d059d268_5" -> "objc_blockMy_manager.blockReleaseNoLeak_1(struct CGImage).d2039f8bbb0530575d5ff258d059d268_7" ;
"objc_blockMy_manager.blockReleaseNoLeak_1(struct CGImage).d2039f8bbb0530575d5ff258d059d268_6" [label="6: Prune (false branch, if) \n n$10=*&newImage:CGImage* [line 24, column 9]\n PRUNE(!n$10, false); [line 24, column 9]\n " shape="invhouse"]
[debug] print procedures in alphabetical order in cfgs Summary: When looking at large CFGs, at least in `xdot`, it's often difficult to find the procedure you're looking for. Sorting the proc names puts them in alphabetical order, which makes searching one procedure easier. Reviewed By: mbouaziz Differential Revision: D7758521 fbshipit-source-id: 8e9997f
7 years ago
[IR] Fix the function hashable_name for ObjC methods Summary: This function had been computing the name for ObjC methods wrong, with only the class name. This was causing wrong error messages in Pulse. The main issue was that `Procname.to_simplified_string` was writing `Classname::methodname` for ObjC methods, which is not the convention. This confused the `hashable_name` funtion. So changing the method name to `Classname.methodname` which is more standard, and this also fixes `hashable_name`. Reviewed By: ngorogiannis, jvillard Differential Revision: D21570880 fbshipit-source-id: 13ed62cf8
5 years ago
"objc_blockMy_manager.blockReleaseNoLeak_1(struct CGImage).d2039f8bbb0530575d5ff258d059d268_6" -> "objc_blockMy_manager.blockReleaseNoLeak_1(struct CGImage).d2039f8bbb0530575d5ff258d059d268_3" ;
"objc_blockMy_manager.blockReleaseNoLeak_1(struct CGImage).d2039f8bbb0530575d5ff258d059d268_7" [label="7: Call _fun_CGImageRelease \n n$11=*&newImage:CGImage* [line 25, column 22]\n n$12=_fun_CGImageRelease(n$11:CGImage*) [line 25, column 7]\n " shape="box"]
[debug] print procedures in alphabetical order in cfgs Summary: When looking at large CFGs, at least in `xdot`, it's often difficult to find the procedure you're looking for. Sorting the proc names puts them in alphabetical order, which makes searching one procedure easier. Reviewed By: mbouaziz Differential Revision: D7758521 fbshipit-source-id: 8e9997f
7 years ago
[IR] Fix the function hashable_name for ObjC methods Summary: This function had been computing the name for ObjC methods wrong, with only the class name. This was causing wrong error messages in Pulse. The main issue was that `Procname.to_simplified_string` was writing `Classname::methodname` for ObjC methods, which is not the convention. This confused the `hashable_name` funtion. So changing the method name to `Classname.methodname` which is more standard, and this also fixes `hashable_name`. Reviewed By: ngorogiannis, jvillard Differential Revision: D21570880 fbshipit-source-id: 13ed62cf8
5 years ago
"objc_blockMy_manager.blockReleaseNoLeak_1(struct CGImage).d2039f8bbb0530575d5ff258d059d268_7" -> "objc_blockMy_manager.blockReleaseNoLeak_1(struct CGImage).d2039f8bbb0530575d5ff258d059d268_3" ;
"blockReleaseNoLeak#My_manager#instance.0c48f80f024250b18a529440f1313af6_1" [label="1: Start My_manager.blockReleaseNoLeak\nFormals: self:My_manager*\nLocals: newImage:CGImage* context:CGContext* z:int b:_fn_(*) \n " color=yellow style=filled]
Fix control-flow graph shape when conditional is last instruction. Summary:public When a conditional is the last instruction, there will be a join node leading directly to the exit node. Some instructions, such as nullification of dead variables, and abstraction, are added to the control flow graph automatically. But, join nodes cannot contain instructions. So when a procedure ends with a conditional, there might be no place to store these instructions. This diff adds one extra node between the join and the exit node in that situation. Reviewed By: jvillard Differential Revision: D3179056 fb-gh-sync-id: 2b9cd7e fbshipit-source-id: 2b9cd7e
9 years ago
[retain cycles] Fix renaming of closures, finds more retain cycles Reviewed By: ddino Differential Revision: D7012360 fbshipit-source-id: 4a972d3
7 years ago
"blockReleaseNoLeak#My_manager#instance.0c48f80f024250b18a529440f1313af6_1" -> "blockReleaseNoLeak#My_manager#instance.0c48f80f024250b18a529440f1313af6_12" ;
[IR] Fix the function hashable_name for ObjC methods Summary: This function had been computing the name for ObjC methods wrong, with only the class name. This was causing wrong error messages in Pulse. The main issue was that `Procname.to_simplified_string` was writing `Classname::methodname` for ObjC methods, which is not the convention. This confused the `hashable_name` funtion. So changing the method name to `Classname.methodname` which is more standard, and this also fixes `hashable_name`. Reviewed By: ngorogiannis, jvillard Differential Revision: D21570880 fbshipit-source-id: 13ed62cf8
5 years ago
"blockReleaseNoLeak#My_manager#instance.0c48f80f024250b18a529440f1313af6_2" [label="2: Exit My_manager.blockReleaseNoLeak \n " color=yellow style=filled]
initial synchronization
10 years ago
[cfg] run pre-analysis lazily in ondemand Summary: This also prints the CFGs *after* pre-analysis for individual procedures in infer-out/captured/<filename>/<proc>.dot. One can also look up the CFGs before pre-analysis in infer-out/captured/proc_cfgs_frontend.dot. Context: I want to add a pre-analysis that needs to look at proc attributes inter-procedurally. For this to make sense it has to happen *after* all of capture, and before analysis. Thus, this diff brings back the lazy running of the pre-analysis like in D15803492, except that we still make sure to run the pre-analyses systematically regardless of the checkers being run by running the pre-analysis from ondemand.ml. Also we don't need to re-introduce the "did_preanalysis" proc attribute for the same reason that the pre-analysis is now run once and for all by ondemand.ml (instead of each individual checker back in the days). This has the benefit of running the pre-analysis only when needed, and the drawback that several concurrent processes analysing the same proc descs will duplicate work. Since pre-analyses are supposed to be very fast I assume that neither is a big deal. If they become more expensive then the benefit gets bigger and the drawback is just the same as with regular analyses. Reviewed By: skcho Differential Revision: D18573920 fbshipit-source-id: de350eaef
5 years ago
"blockReleaseNoLeak#My_manager#instance.0c48f80f024250b18a529440f1313af6_3" [label="3: Return Stmt \n n$0=*&z:int [line 30, column 10]\n *&return:int=n$0 [line 30, column 3]\n " shape="box"]
initial synchronization
10 years ago
[retain cycles] Fix renaming of closures, finds more retain cycles Reviewed By: ddino Differential Revision: D7012360 fbshipit-source-id: 4a972d3
7 years ago
"blockReleaseNoLeak#My_manager#instance.0c48f80f024250b18a529440f1313af6_3" -> "blockReleaseNoLeak#My_manager#instance.0c48f80f024250b18a529440f1313af6_2" ;
"blockReleaseNoLeak#My_manager#instance.0c48f80f024250b18a529440f1313af6_4" [label="4: + \n " ]
initial synchronization
10 years ago
[retain cycles] Fix renaming of closures, finds more retain cycles Reviewed By: ddino Differential Revision: D7012360 fbshipit-source-id: 4a972d3
7 years ago
"blockReleaseNoLeak#My_manager#instance.0c48f80f024250b18a529440f1313af6_4" -> "blockReleaseNoLeak#My_manager#instance.0c48f80f024250b18a529440f1313af6_3" ;
[cfg] run pre-analysis lazily in ondemand Summary: This also prints the CFGs *after* pre-analysis for individual procedures in infer-out/captured/<filename>/<proc>.dot. One can also look up the CFGs before pre-analysis in infer-out/captured/proc_cfgs_frontend.dot. Context: I want to add a pre-analysis that needs to look at proc attributes inter-procedurally. For this to make sense it has to happen *after* all of capture, and before analysis. Thus, this diff brings back the lazy running of the pre-analysis like in D15803492, except that we still make sure to run the pre-analyses systematically regardless of the checkers being run by running the pre-analysis from ondemand.ml. Also we don't need to re-introduce the "did_preanalysis" proc attribute for the same reason that the pre-analysis is now run once and for all by ondemand.ml (instead of each individual checker back in the days). This has the benefit of running the pre-analysis only when needed, and the drawback that several concurrent processes analysing the same proc descs will duplicate work. Since pre-analyses are supposed to be very fast I assume that neither is a big deal. If they become more expensive then the benefit gets bigger and the drawback is just the same as with regular analyses. Reviewed By: skcho Differential Revision: D18573920 fbshipit-source-id: de350eaef
5 years ago
"blockReleaseNoLeak#My_manager#instance.0c48f80f024250b18a529440f1313af6_5" [label="5: Prune (true branch, if) \n n$1=*&context:CGContext* [line 28, column 7]\n PRUNE(n$1, true); [line 28, column 7]\n " shape="invhouse"]
initial synchronization
10 years ago
[retain cycles] Fix renaming of closures, finds more retain cycles Reviewed By: ddino Differential Revision: D7012360 fbshipit-source-id: 4a972d3
7 years ago
"blockReleaseNoLeak#My_manager#instance.0c48f80f024250b18a529440f1313af6_5" -> "blockReleaseNoLeak#My_manager#instance.0c48f80f024250b18a529440f1313af6_7" ;
[cfg] run pre-analysis lazily in ondemand Summary: This also prints the CFGs *after* pre-analysis for individual procedures in infer-out/captured/<filename>/<proc>.dot. One can also look up the CFGs before pre-analysis in infer-out/captured/proc_cfgs_frontend.dot. Context: I want to add a pre-analysis that needs to look at proc attributes inter-procedurally. For this to make sense it has to happen *after* all of capture, and before analysis. Thus, this diff brings back the lazy running of the pre-analysis like in D15803492, except that we still make sure to run the pre-analyses systematically regardless of the checkers being run by running the pre-analysis from ondemand.ml. Also we don't need to re-introduce the "did_preanalysis" proc attribute for the same reason that the pre-analysis is now run once and for all by ondemand.ml (instead of each individual checker back in the days). This has the benefit of running the pre-analysis only when needed, and the drawback that several concurrent processes analysing the same proc descs will duplicate work. Since pre-analyses are supposed to be very fast I assume that neither is a big deal. If they become more expensive then the benefit gets bigger and the drawback is just the same as with regular analyses. Reviewed By: skcho Differential Revision: D18573920 fbshipit-source-id: de350eaef
5 years ago
"blockReleaseNoLeak#My_manager#instance.0c48f80f024250b18a529440f1313af6_6" [label="6: Prune (false branch, if) \n n$1=*&context:CGContext* [line 28, column 7]\n PRUNE(!n$1, false); [line 28, column 7]\n " shape="invhouse"]
initial synchronization
10 years ago
[retain cycles] Fix renaming of closures, finds more retain cycles Reviewed By: ddino Differential Revision: D7012360 fbshipit-source-id: 4a972d3
7 years ago
"blockReleaseNoLeak#My_manager#instance.0c48f80f024250b18a529440f1313af6_6" -> "blockReleaseNoLeak#My_manager#instance.0c48f80f024250b18a529440f1313af6_4" ;
[cfg] run pre-analysis lazily in ondemand Summary: This also prints the CFGs *after* pre-analysis for individual procedures in infer-out/captured/<filename>/<proc>.dot. One can also look up the CFGs before pre-analysis in infer-out/captured/proc_cfgs_frontend.dot. Context: I want to add a pre-analysis that needs to look at proc attributes inter-procedurally. For this to make sense it has to happen *after* all of capture, and before analysis. Thus, this diff brings back the lazy running of the pre-analysis like in D15803492, except that we still make sure to run the pre-analyses systematically regardless of the checkers being run by running the pre-analysis from ondemand.ml. Also we don't need to re-introduce the "did_preanalysis" proc attribute for the same reason that the pre-analysis is now run once and for all by ondemand.ml (instead of each individual checker back in the days). This has the benefit of running the pre-analysis only when needed, and the drawback that several concurrent processes analysing the same proc descs will duplicate work. Since pre-analyses are supposed to be very fast I assume that neither is a big deal. If they become more expensive then the benefit gets bigger and the drawback is just the same as with regular analyses. Reviewed By: skcho Differential Revision: D18573920 fbshipit-source-id: de350eaef
5 years ago
"blockReleaseNoLeak#My_manager#instance.0c48f80f024250b18a529440f1313af6_7" [label="7: Call _fun_CGContextRelease \n n$2=*&context:CGContext* [line 29, column 22]\n n$3=_fun_CGContextRelease(n$2:CGContext*) [line 29, column 5]\n " shape="box"]
initial synchronization
10 years ago
[retain cycles] Fix renaming of closures, finds more retain cycles Reviewed By: ddino Differential Revision: D7012360 fbshipit-source-id: 4a972d3
7 years ago
"blockReleaseNoLeak#My_manager#instance.0c48f80f024250b18a529440f1313af6_7" -> "blockReleaseNoLeak#My_manager#instance.0c48f80f024250b18a529440f1313af6_4" ;
[cfg] run pre-analysis lazily in ondemand Summary: This also prints the CFGs *after* pre-analysis for individual procedures in infer-out/captured/<filename>/<proc>.dot. One can also look up the CFGs before pre-analysis in infer-out/captured/proc_cfgs_frontend.dot. Context: I want to add a pre-analysis that needs to look at proc attributes inter-procedurally. For this to make sense it has to happen *after* all of capture, and before analysis. Thus, this diff brings back the lazy running of the pre-analysis like in D15803492, except that we still make sure to run the pre-analyses systematically regardless of the checkers being run by running the pre-analysis from ondemand.ml. Also we don't need to re-introduce the "did_preanalysis" proc attribute for the same reason that the pre-analysis is now run once and for all by ondemand.ml (instead of each individual checker back in the days). This has the benefit of running the pre-analysis only when needed, and the drawback that several concurrent processes analysing the same proc descs will duplicate work. Since pre-analyses are supposed to be very fast I assume that neither is a big deal. If they become more expensive then the benefit gets bigger and the drawback is just the same as with regular analyses. Reviewed By: skcho Differential Revision: D18573920 fbshipit-source-id: de350eaef
5 years ago
"blockReleaseNoLeak#My_manager#instance.0c48f80f024250b18a529440f1313af6_8" [label="8: Call n$6 \n n$6=*&b:_fn_(*) [line 27, column 3]\n n$7=*&z:int [line 27, column 5]\n n$8=n$6(n$7:int) objc_block [line 27, column 3]\n " shape="box"]
initial synchronization
10 years ago
[retain cycles] Fix renaming of closures, finds more retain cycles Reviewed By: ddino Differential Revision: D7012360 fbshipit-source-id: 4a972d3
7 years ago
"blockReleaseNoLeak#My_manager#instance.0c48f80f024250b18a529440f1313af6_8" -> "blockReleaseNoLeak#My_manager#instance.0c48f80f024250b18a529440f1313af6_5" ;
"blockReleaseNoLeak#My_manager#instance.0c48f80f024250b18a529440f1313af6_8" -> "blockReleaseNoLeak#My_manager#instance.0c48f80f024250b18a529440f1313af6_6" ;
[IR] Fix the function hashable_name for ObjC methods Summary: This function had been computing the name for ObjC methods wrong, with only the class name. This was causing wrong error messages in Pulse. The main issue was that `Procname.to_simplified_string` was writing `Classname::methodname` for ObjC methods, which is not the convention. This confused the `hashable_name` funtion. So changing the method name to `Classname.methodname` which is more standard, and this also fixes `hashable_name`. Reviewed By: ngorogiannis, jvillard Differential Revision: D21570880 fbshipit-source-id: 13ed62cf8
5 years ago
"blockReleaseNoLeak#My_manager#instance.0c48f80f024250b18a529440f1313af6_9" [label="9: BinaryOperatorStmt: Assign \n n$9=*&newImage:CGImage* [line 23, column 7]\n *&b:_fn_(*)=(_fun_objc_blockMy_manager.blockReleaseNoLeak_1,(n$9 &newImage:CGImage*)) [line 23, column 3]\n " shape="box"]
initial synchronization
10 years ago
[retain cycles] Fix renaming of closures, finds more retain cycles Reviewed By: ddino Differential Revision: D7012360 fbshipit-source-id: 4a972d3
7 years ago
"blockReleaseNoLeak#My_manager#instance.0c48f80f024250b18a529440f1313af6_9" -> "blockReleaseNoLeak#My_manager#instance.0c48f80f024250b18a529440f1313af6_8" ;
[cfg] run pre-analysis lazily in ondemand Summary: This also prints the CFGs *after* pre-analysis for individual procedures in infer-out/captured/<filename>/<proc>.dot. One can also look up the CFGs before pre-analysis in infer-out/captured/proc_cfgs_frontend.dot. Context: I want to add a pre-analysis that needs to look at proc attributes inter-procedurally. For this to make sense it has to happen *after* all of capture, and before analysis. Thus, this diff brings back the lazy running of the pre-analysis like in D15803492, except that we still make sure to run the pre-analyses systematically regardless of the checkers being run by running the pre-analysis from ondemand.ml. Also we don't need to re-introduce the "did_preanalysis" proc attribute for the same reason that the pre-analysis is now run once and for all by ondemand.ml (instead of each individual checker back in the days). This has the benefit of running the pre-analysis only when needed, and the drawback that several concurrent processes analysing the same proc descs will duplicate work. Since pre-analyses are supposed to be very fast I assume that neither is a big deal. If they become more expensive then the benefit gets bigger and the drawback is just the same as with regular analyses. Reviewed By: skcho Differential Revision: D18573920 fbshipit-source-id: de350eaef
5 years ago
"blockReleaseNoLeak#My_manager#instance.0c48f80f024250b18a529440f1313af6_10" [label="10: DeclStmt \n VARIABLE_DECLARED(newImage:CGImage*); [line 22, column 3]\n n$15=*&context:CGContext* [line 22, column 52]\n n$16=_fun_CGBitmapContextCreateImage(n$15:CGContext*) [line 22, column 25]\n *&newImage:CGImage*=n$16 [line 22, column 3]\n " shape="box"]
initial synchronization
10 years ago
[retain cycles] Fix renaming of closures, finds more retain cycles Reviewed By: ddino Differential Revision: D7012360 fbshipit-source-id: 4a972d3
7 years ago
"blockReleaseNoLeak#My_manager#instance.0c48f80f024250b18a529440f1313af6_10" -> "blockReleaseNoLeak#My_manager#instance.0c48f80f024250b18a529440f1313af6_9" ;
[cfg] run pre-analysis lazily in ondemand Summary: This also prints the CFGs *after* pre-analysis for individual procedures in infer-out/captured/<filename>/<proc>.dot. One can also look up the CFGs before pre-analysis in infer-out/captured/proc_cfgs_frontend.dot. Context: I want to add a pre-analysis that needs to look at proc attributes inter-procedurally. For this to make sense it has to happen *after* all of capture, and before analysis. Thus, this diff brings back the lazy running of the pre-analysis like in D15803492, except that we still make sure to run the pre-analyses systematically regardless of the checkers being run by running the pre-analysis from ondemand.ml. Also we don't need to re-introduce the "did_preanalysis" proc attribute for the same reason that the pre-analysis is now run once and for all by ondemand.ml (instead of each individual checker back in the days). This has the benefit of running the pre-analysis only when needed, and the drawback that several concurrent processes analysing the same proc descs will duplicate work. Since pre-analyses are supposed to be very fast I assume that neither is a big deal. If they become more expensive then the benefit gets bigger and the drawback is just the same as with regular analyses. Reviewed By: skcho Differential Revision: D18573920 fbshipit-source-id: de350eaef
5 years ago
"blockReleaseNoLeak#My_manager#instance.0c48f80f024250b18a529440f1313af6_11" [label="11: DeclStmt \n VARIABLE_DECLARED(context:CGContext*); [line 21, column 3]\n n$17=_fun_CGBitmapContextCreate(null:void*,(unsigned long)0:unsigned long,(unsigned long)0:unsigned long,(unsigned long)8:unsigned long,(unsigned long)0:unsigned long,null:CGColorSpace*,(unsigned int)0:unsigned int) [line 21, column 26]\n *&context:CGContext*=n$17 [line 21, column 3]\n " shape="box"]
initial synchronization
10 years ago
[retain cycles] Fix renaming of closures, finds more retain cycles Reviewed By: ddino Differential Revision: D7012360 fbshipit-source-id: 4a972d3
7 years ago
"blockReleaseNoLeak#My_manager#instance.0c48f80f024250b18a529440f1313af6_11" -> "blockReleaseNoLeak#My_manager#instance.0c48f80f024250b18a529440f1313af6_10" ;
[SIL] change `variable_initialization()` builtin to a new auxiliary instruction Summary: Instead of emitting an ad-hoc builtin on variable declaration emit a new metadata instruction. This allows us to remove the code matching on that ad-hoc builtin that had to be inserted in several checkers. Inferbo & pulse used that information meaningfully and had to undergo some minor changes to cope with the new metada instruction. Reviewed By: ezgicicek Differential Revision: D14833100 fbshipit-source-id: 9b3009d22
6 years ago
"blockReleaseNoLeak#My_manager#instance.0c48f80f024250b18a529440f1313af6_12" [label="12: DeclStmt \n VARIABLE_DECLARED(z:int); [line 20, column 3]\n *&z:int=3 [line 20, column 3]\n " shape="box"]
initial synchronization
10 years ago
[retain cycles] Fix renaming of closures, finds more retain cycles Reviewed By: ddino Differential Revision: D7012360 fbshipit-source-id: 4a972d3
7 years ago
"blockReleaseNoLeak#My_manager#instance.0c48f80f024250b18a529440f1313af6_12" -> "blockReleaseNoLeak#My_manager#instance.0c48f80f024250b18a529440f1313af6_11" ;
[clang] Adding implicit implementation of dealloc methods to ObjC classes Summary: This models ARC implementation of dealloc, see https://clang.llvm.org/docs/AutomaticReferenceCounting.html#dealloc. Dealloc methods can be added to ObjC classes to free C memory for example, but the deallocation of the ObjC instance variables of the object is done automatically. So here we add this explicitly to Infer: 1. First, we add an empty dealloc method when it is not written explicitly. 2. For each dealloc method (including the implicitly added ones) we add calls to dealloc of the ObjC instance variables. Reviewed By: jvillard Differential Revision: D21883546 fbshipit-source-id: f5d4930f2
5 years ago
"dealloc#My_manager#instance.62748019ba808efecf04f93dd9aba402_1" [label="1: Start My_manager.dealloc\nFormals: self:My_manager*\nLocals: \n " color=yellow style=filled]
"dealloc#My_manager#instance.62748019ba808efecf04f93dd9aba402_1" -> "dealloc#My_manager#instance.62748019ba808efecf04f93dd9aba402_3" ;
"dealloc#My_manager#instance.62748019ba808efecf04f93dd9aba402_2" [label="2: Exit My_manager.dealloc \n " color=yellow style=filled]
"dealloc#My_manager#instance.62748019ba808efecf04f93dd9aba402_3" [label="3: Call dealloc \n " shape="box"]
"dealloc#My_manager#instance.62748019ba808efecf04f93dd9aba402_3" -> "dealloc#My_manager#instance.62748019ba808efecf04f93dd9aba402_2" ;
initial synchronization
10 years ago
}