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 'c67f3d5753'
${ noResults }
infer_clone/infer/tests/codetoanalyze/cpp/shared/templates/class_specialization.cpp.dot

108 lines
11 KiB
Raw Normal View History Unescape

[C++] update fcp to deal with template specializations Summary: Update facebook-clang-plugins to fetch the fix of template arguments of template specialized classes. update-submodule: facebook-clang-plugins Reviewed By: grievejia Differential Revision: D5582942 fbshipit-source-id: b6d2efe
7 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 {
Get rid of Declare_locals Reviewed By: jeremydubreil Differential Revision: D9234331 fbshipit-source-id: 70443eabe
6 years ago
"foo_int#class_specialization#18011277194514159170.29412bbb7345cd5150bdd3239c145d19_1" [label="1: Start class_specialization::foo_int\nFormals: \nLocals: z:int b:class_specialization::Derived<int> \n " color=yellow style=filled]
[C++] update fcp to deal with template specializations Summary: Update facebook-clang-plugins to fetch the fix of template arguments of template specialized classes. update-submodule: facebook-clang-plugins Reviewed By: grievejia Differential Revision: D5582942 fbshipit-source-id: b6d2efe
7 years ago
[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
"foo_int#class_specialization#18011277194514159170.29412bbb7345cd5150bdd3239c145d19_1" -> "foo_int#class_specialization#18011277194514159170.29412bbb7345cd5150bdd3239c145d19_5" ;
[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
"foo_int#class_specialization#18011277194514159170.29412bbb7345cd5150bdd3239c145d19_2" [label="2: Exit class_specialization::foo_int \n " color=yellow style=filled]
[C++] update fcp to deal with template specializations Summary: Update facebook-clang-plugins to fetch the fix of template arguments of template specialized classes. update-submodule: facebook-clang-plugins Reviewed By: grievejia Differential Revision: D5582942 fbshipit-source-id: b6d2efe
7 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
"foo_int#class_specialization#18011277194514159170.29412bbb7345cd5150bdd3239c145d19_3" [label="3: DeclStmt \n VARIABLE_DECLARED(z:int); [line 33, column 3]\n n$0=*&b.x:int [line 33, column 15]\n *&z:int=(1 / n$0) [line 33, column 3]\n " shape="box"]
[C++] update fcp to deal with template specializations Summary: Update facebook-clang-plugins to fetch the fix of template arguments of template specialized classes. update-submodule: facebook-clang-plugins Reviewed By: grievejia Differential Revision: D5582942 fbshipit-source-id: b6d2efe
7 years ago
[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
"foo_int#class_specialization#18011277194514159170.29412bbb7345cd5150bdd3239c145d19_3" -> "foo_int#class_specialization#18011277194514159170.29412bbb7345cd5150bdd3239c145d19_2" ;
[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
"foo_int#class_specialization#18011277194514159170.29412bbb7345cd5150bdd3239c145d19_4" [label="4: Call _fun_class_specialization::Derived<int>::foo \n _=*&b:class_specialization::Derived<int> [line 32, column 3]\n n$2=_fun_class_specialization::Derived<int>::foo(&b:class_specialization::Derived<int>&,0:int) [line 32, column 3]\n " shape="box"]
[C++] update fcp to deal with template specializations Summary: Update facebook-clang-plugins to fetch the fix of template arguments of template specialized classes. update-submodule: facebook-clang-plugins Reviewed By: grievejia Differential Revision: D5582942 fbshipit-source-id: b6d2efe
7 years ago
[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
"foo_int#class_specialization#18011277194514159170.29412bbb7345cd5150bdd3239c145d19_4" -> "foo_int#class_specialization#18011277194514159170.29412bbb7345cd5150bdd3239c145d19_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
"foo_int#class_specialization#18011277194514159170.29412bbb7345cd5150bdd3239c145d19_5" [label="5: DeclStmt \n VARIABLE_DECLARED(b:class_specialization::Derived<int>); [line 31, column 3]\n n$3=_fun_class_specialization::Derived<int>::Derived(&b:class_specialization::Derived<int>*) [line 31, column 16]\n " shape="box"]
[C++] update fcp to deal with template specializations Summary: Update facebook-clang-plugins to fetch the fix of template arguments of template specialized classes. update-submodule: facebook-clang-plugins Reviewed By: grievejia Differential Revision: D5582942 fbshipit-source-id: b6d2efe
7 years ago
[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
"foo_int#class_specialization#18011277194514159170.29412bbb7345cd5150bdd3239c145d19_5" -> "foo_int#class_specialization#18011277194514159170.29412bbb7345cd5150bdd3239c145d19_4" ;
Get rid of Declare_locals Reviewed By: jeremydubreil Differential Revision: D9234331 fbshipit-source-id: 70443eabe
6 years ago
"foo_intptr#class_specialization#3914514069521239538.096096ddd8eb9462872f535952d6e0a5_1" [label="1: Start class_specialization::foo_intptr\nFormals: \nLocals: x:int b:class_specialization::Derived<int*> \n " color=yellow style=filled]
[C++] update fcp to deal with template specializations Summary: Update facebook-clang-plugins to fetch the fix of template arguments of template specialized classes. update-submodule: facebook-clang-plugins Reviewed By: grievejia Differential Revision: D5582942 fbshipit-source-id: b6d2efe
7 years ago
[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
"foo_intptr#class_specialization#3914514069521239538.096096ddd8eb9462872f535952d6e0a5_1" -> "foo_intptr#class_specialization#3914514069521239538.096096ddd8eb9462872f535952d6e0a5_5" ;
[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
"foo_intptr#class_specialization#3914514069521239538.096096ddd8eb9462872f535952d6e0a5_2" [label="2: Exit class_specialization::foo_intptr \n " color=yellow style=filled]
[C++] update fcp to deal with template specializations Summary: Update facebook-clang-plugins to fetch the fix of template arguments of template specialized classes. update-submodule: facebook-clang-plugins Reviewed By: grievejia Differential Revision: D5582942 fbshipit-source-id: b6d2efe
7 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
"foo_intptr#class_specialization#3914514069521239538.096096ddd8eb9462872f535952d6e0a5_3" [label="3: DeclStmt \n VARIABLE_DECLARED(x:int); [line 27, column 3]\n n$0=*&b.x:int* [line 27, column 12]\n n$1=*n$0:int [line 27, column 11]\n *&x:int=n$1 [line 27, column 3]\n " shape="box"]
[C++] update fcp to deal with template specializations Summary: Update facebook-clang-plugins to fetch the fix of template arguments of template specialized classes. update-submodule: facebook-clang-plugins Reviewed By: grievejia Differential Revision: D5582942 fbshipit-source-id: b6d2efe
7 years ago
[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
"foo_intptr#class_specialization#3914514069521239538.096096ddd8eb9462872f535952d6e0a5_3" -> "foo_intptr#class_specialization#3914514069521239538.096096ddd8eb9462872f535952d6e0a5_2" ;
[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
"foo_intptr#class_specialization#3914514069521239538.096096ddd8eb9462872f535952d6e0a5_4" [label="4: Call _fun_class_specialization::Derived<int*>::foo2 \n _=*&b:class_specialization::Derived<int*> [line 26, column 3]\n n$3=_fun_class_specialization::Derived<int*>::foo2(&b:class_specialization::Derived<int*>&,null:int*) [line 26, column 3]\n " shape="box"]
[C++] update fcp to deal with template specializations Summary: Update facebook-clang-plugins to fetch the fix of template arguments of template specialized classes. update-submodule: facebook-clang-plugins Reviewed By: grievejia Differential Revision: D5582942 fbshipit-source-id: b6d2efe
7 years ago
[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
"foo_intptr#class_specialization#3914514069521239538.096096ddd8eb9462872f535952d6e0a5_4" -> "foo_intptr#class_specialization#3914514069521239538.096096ddd8eb9462872f535952d6e0a5_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
"foo_intptr#class_specialization#3914514069521239538.096096ddd8eb9462872f535952d6e0a5_5" [label="5: DeclStmt \n VARIABLE_DECLARED(b:class_specialization::Derived<int*>); [line 25, column 3]\n n$4=_fun_class_specialization::Derived<int*>::Derived(&b:class_specialization::Derived<int*>*) [line 25, column 17]\n " shape="box"]
[C++] update fcp to deal with template specializations Summary: Update facebook-clang-plugins to fetch the fix of template arguments of template specialized classes. update-submodule: facebook-clang-plugins Reviewed By: grievejia Differential Revision: D5582942 fbshipit-source-id: b6d2efe
7 years ago
[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
"foo_intptr#class_specialization#3914514069521239538.096096ddd8eb9462872f535952d6e0a5_5" -> "foo_intptr#class_specialization#3914514069521239538.096096ddd8eb9462872f535952d6e0a5_4" ;
RFC: stop using _ to separate ObjC/C++ class name from method in Typ.Procname.to_string Reviewed By: jvillard Differential Revision: D14736442 fbshipit-source-id: 500df354b
6 years ago
"Base#Base<int*>#class_specialization#{14101392445423095049}.4481221d683f8e54c4527519cddc792a_1" [label="1: Start class_specialization::Base<int*>::Base\nFormals: this:class_specialization::Base<int*>*\nLocals: \n " color=yellow style=filled]
[C++] update fcp to deal with template specializations Summary: Update facebook-clang-plugins to fetch the fix of template arguments of template specialized classes. update-submodule: facebook-clang-plugins Reviewed By: grievejia Differential Revision: D5582942 fbshipit-source-id: b6d2efe
7 years ago
[clang] update clang plugin to hash mangled names Summary: With this change and the previous facebook-clang-plugins change, infer no longer exhausts the biniou buffer when reading the serialized C++ AST. update-submodule: facebook-clang-plugins Reviewed By: mbouaziz Differential Revision: D5891081 fbshipit-source-id: cf48eac
7 years ago
"Base#Base<int*>#class_specialization#{14101392445423095049}.4481221d683f8e54c4527519cddc792a_1" -> "Base#Base<int*>#class_specialization#{14101392445423095049}.4481221d683f8e54c4527519cddc792a_2" ;
RFC: stop using _ to separate ObjC/C++ class name from method in Typ.Procname.to_string Reviewed By: jvillard Differential Revision: D14736442 fbshipit-source-id: 500df354b
6 years ago
"Base#Base<int*>#class_specialization#{14101392445423095049}.4481221d683f8e54c4527519cddc792a_2" [label="2: Exit class_specialization::Base<int*>::Base \n " color=yellow style=filled]
[C++] update fcp to deal with template specializations Summary: Update facebook-clang-plugins to fetch the fix of template arguments of template specialized classes. update-submodule: facebook-clang-plugins Reviewed By: grievejia Differential Revision: D5582942 fbshipit-source-id: b6d2efe
7 years ago
RFC: stop using _ to separate ObjC/C++ class name from method in Typ.Procname.to_string Reviewed By: jvillard Differential Revision: D14736442 fbshipit-source-id: 500df354b
6 years ago
"Base#Base<int>#class_specialization#{16658552199303145313}.b6aa2df9eb4873c08c322ab298261cf8_1" [label="1: Start class_specialization::Base<int>::Base\nFormals: this:class_specialization::Base<int>*\nLocals: \n " color=yellow style=filled]
[C++] update fcp to deal with template specializations Summary: Update facebook-clang-plugins to fetch the fix of template arguments of template specialized classes. update-submodule: facebook-clang-plugins Reviewed By: grievejia Differential Revision: D5582942 fbshipit-source-id: b6d2efe
7 years ago
[clang] update clang plugin to hash mangled names Summary: With this change and the previous facebook-clang-plugins change, infer no longer exhausts the biniou buffer when reading the serialized C++ AST. update-submodule: facebook-clang-plugins Reviewed By: mbouaziz Differential Revision: D5891081 fbshipit-source-id: cf48eac
7 years ago
"Base#Base<int>#class_specialization#{16658552199303145313}.b6aa2df9eb4873c08c322ab298261cf8_1" -> "Base#Base<int>#class_specialization#{16658552199303145313}.b6aa2df9eb4873c08c322ab298261cf8_2" ;
RFC: stop using _ to separate ObjC/C++ class name from method in Typ.Procname.to_string Reviewed By: jvillard Differential Revision: D14736442 fbshipit-source-id: 500df354b
6 years ago
"Base#Base<int>#class_specialization#{16658552199303145313}.b6aa2df9eb4873c08c322ab298261cf8_2" [label="2: Exit class_specialization::Base<int>::Base \n " color=yellow style=filled]
[C++] update fcp to deal with template specializations Summary: Update facebook-clang-plugins to fetch the fix of template arguments of template specialized classes. update-submodule: facebook-clang-plugins Reviewed By: grievejia Differential Revision: D5582942 fbshipit-source-id: b6d2efe
7 years ago
RFC: stop using _ to separate ObjC/C++ class name from method in Typ.Procname.to_string Reviewed By: jvillard Differential Revision: D14736442 fbshipit-source-id: 500df354b
6 years ago
"foo2#Derived<int*>#class_specialization#(12167928122938213289).9c7a2e679a7d7dcf0338960c56f01bd4_1" [label="1: Start class_specialization::Derived<int*>::foo2\nFormals: this:class_specialization::Derived<int*>* t:int*\nLocals: \n " color=yellow style=filled]
[C++] update fcp to deal with template specializations Summary: Update facebook-clang-plugins to fetch the fix of template arguments of template specialized classes. update-submodule: facebook-clang-plugins Reviewed By: grievejia Differential Revision: D5582942 fbshipit-source-id: b6d2efe
7 years ago
[clang] Adding parameters as part of the procname for C++/ObjC methods and ObjC blocks Reviewed By: mbouaziz Differential Revision: D8237112 fbshipit-source-id: c0ec4b4
7 years ago
"foo2#Derived<int*>#class_specialization#(12167928122938213289).9c7a2e679a7d7dcf0338960c56f01bd4_1" -> "foo2#Derived<int*>#class_specialization#(12167928122938213289).9c7a2e679a7d7dcf0338960c56f01bd4_3" ;
RFC: stop using _ to separate ObjC/C++ class name from method in Typ.Procname.to_string Reviewed By: jvillard Differential Revision: D14736442 fbshipit-source-id: 500df354b
6 years ago
"foo2#Derived<int*>#class_specialization#(12167928122938213289).9c7a2e679a7d7dcf0338960c56f01bd4_2" [label="2: Exit class_specialization::Derived<int*>::foo2 \n " color=yellow style=filled]
[C++] update fcp to deal with template specializations Summary: Update facebook-clang-plugins to fetch the fix of template arguments of template specialized classes. update-submodule: facebook-clang-plugins Reviewed By: grievejia Differential Revision: D5582942 fbshipit-source-id: b6d2efe
7 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
"foo2#Derived<int*>#class_specialization#(12167928122938213289).9c7a2e679a7d7dcf0338960c56f01bd4_3" [label="3: BinaryOperatorStmt: Assign \n n$0=*&this:class_specialization::Derived<int*>* [line 21, column 21]\n n$1=*&t:int* [line 21, column 31]\n *n$0.x:int*=n$1 [line 21, column 21]\n " shape="box"]
[C++] update fcp to deal with template specializations Summary: Update facebook-clang-plugins to fetch the fix of template arguments of template specialized classes. update-submodule: facebook-clang-plugins Reviewed By: grievejia Differential Revision: D5582942 fbshipit-source-id: b6d2efe
7 years ago
[clang] Adding parameters as part of the procname for C++/ObjC methods and ObjC blocks Reviewed By: mbouaziz Differential Revision: D8237112 fbshipit-source-id: c0ec4b4
7 years ago
"foo2#Derived<int*>#class_specialization#(12167928122938213289).9c7a2e679a7d7dcf0338960c56f01bd4_3" -> "foo2#Derived<int*>#class_specialization#(12167928122938213289).9c7a2e679a7d7dcf0338960c56f01bd4_2" ;
RFC: stop using _ to separate ObjC/C++ class name from method in Typ.Procname.to_string Reviewed By: jvillard Differential Revision: D14736442 fbshipit-source-id: 500df354b
6 years ago
"Derived#Derived<int*>#class_specialization#{6947111178756325946}.2484a8b63b0d0003a390b6e57428fee2_1" [label="1: Start class_specialization::Derived<int*>::Derived\nFormals: this:class_specialization::Derived<int*>*\nLocals: \n " color=yellow style=filled]
fix infinitely-expanding types in the backend Summary: Simple instance of the problem: analyzing the following program times out. ``` #include <tuple> void foo() { std::tuple<std::tuple<int>> x; } ``` Replacing `std::tuple<std::tuple<int>>` by `std::tuple<int>` makes the analysis terminate. In the AST, both tuple<tuple<int>> and tuple<int> have the same template specialization type: "Pack" (which means we're supposed to go look into the arguments of the template to get their values). This is not information enough and that's the plugin fault. On the backend side, this means that two types have the same Typ.Name.t, namely "std::tuple<_>", so they collide in the tenv. The definition of tuple<tuple<int>> is the one making it into the tenv. One of the fields of the corresponding CxxRecord is of type "tuple<int>", which we see as the same "tuple<_>", which causes the loop. update-submodule: facebook-clang-plugins Reviewed By: mbouaziz Differential Revision: D5775840 fbshipit-source-id: 0528604
7 years ago
[clang] Adding parameters as part of the procname for C++/ObjC methods and ObjC blocks Reviewed By: mbouaziz Differential Revision: D8237112 fbshipit-source-id: c0ec4b4
7 years ago
"Derived#Derived<int*>#class_specialization#{6947111178756325946}.2484a8b63b0d0003a390b6e57428fee2_1" -> "Derived#Derived<int*>#class_specialization#{6947111178756325946}.2484a8b63b0d0003a390b6e57428fee2_3" ;
RFC: stop using _ to separate ObjC/C++ class name from method in Typ.Procname.to_string Reviewed By: jvillard Differential Revision: D14736442 fbshipit-source-id: 500df354b
6 years ago
"Derived#Derived<int*>#class_specialization#{6947111178756325946}.2484a8b63b0d0003a390b6e57428fee2_2" [label="2: Exit class_specialization::Derived<int*>::Derived \n " color=yellow style=filled]
fix infinitely-expanding types in the backend Summary: Simple instance of the problem: analyzing the following program times out. ``` #include <tuple> void foo() { std::tuple<std::tuple<int>> x; } ``` Replacing `std::tuple<std::tuple<int>>` by `std::tuple<int>` makes the analysis terminate. In the AST, both tuple<tuple<int>> and tuple<int> have the same template specialization type: "Pack" (which means we're supposed to go look into the arguments of the template to get their values). This is not information enough and that's the plugin fault. On the backend side, this means that two types have the same Typ.Name.t, namely "std::tuple<_>", so they collide in the tenv. The definition of tuple<tuple<int>> is the one making it into the tenv. One of the fields of the corresponding CxxRecord is of type "tuple<int>", which we see as the same "tuple<_>", which causes the loop. update-submodule: facebook-clang-plugins Reviewed By: mbouaziz Differential Revision: D5775840 fbshipit-source-id: 0528604
7 years ago
[clang] fix order of translation for [this] Summary: We need to make sure a node is created to avoid instructions appearing in the wrong order in the final CFG. Reviewed By: da319 Differential Revision: D25784405 fbshipit-source-id: 3ef27d712
4 years ago
"Derived#Derived<int*>#class_specialization#{6947111178756325946}.2484a8b63b0d0003a390b6e57428fee2_3" [label="3: Constructor Init \n n$1=*&this:class_specialization::Derived<int*>* [line 20, column 8]\n " shape="box"]
fix infinitely-expanding types in the backend Summary: Simple instance of the problem: analyzing the following program times out. ``` #include <tuple> void foo() { std::tuple<std::tuple<int>> x; } ``` Replacing `std::tuple<std::tuple<int>>` by `std::tuple<int>` makes the analysis terminate. In the AST, both tuple<tuple<int>> and tuple<int> have the same template specialization type: "Pack" (which means we're supposed to go look into the arguments of the template to get their values). This is not information enough and that's the plugin fault. On the backend side, this means that two types have the same Typ.Name.t, namely "std::tuple<_>", so they collide in the tenv. The definition of tuple<tuple<int>> is the one making it into the tenv. One of the fields of the corresponding CxxRecord is of type "tuple<int>", which we see as the same "tuple<_>", which causes the loop. update-submodule: facebook-clang-plugins Reviewed By: mbouaziz Differential Revision: D5775840 fbshipit-source-id: 0528604
7 years ago
[clang] fix order of translation for [this] Summary: We need to make sure a node is created to avoid instructions appearing in the wrong order in the final CFG. Reviewed By: da319 Differential Revision: D25784405 fbshipit-source-id: 3ef27d712
4 years ago
"Derived#Derived<int*>#class_specialization#{6947111178756325946}.2484a8b63b0d0003a390b6e57428fee2_3" -> "Derived#Derived<int*>#class_specialization#{6947111178756325946}.2484a8b63b0d0003a390b6e57428fee2_4" ;
"Derived#Derived<int*>#class_specialization#{6947111178756325946}.2484a8b63b0d0003a390b6e57428fee2_4" [label="4: Constructor Init \n n$2=_fun_class_specialization::Base<int*>::Base(n$1:class_specialization::Derived<int*>*) [line 20, column 8]\n " shape="box"]
"Derived#Derived<int*>#class_specialization#{6947111178756325946}.2484a8b63b0d0003a390b6e57428fee2_4" -> "Derived#Derived<int*>#class_specialization#{6947111178756325946}.2484a8b63b0d0003a390b6e57428fee2_2" ;
RFC: stop using _ to separate ObjC/C++ class name from method in Typ.Procname.to_string Reviewed By: jvillard Differential Revision: D14736442 fbshipit-source-id: 500df354b
6 years ago
"foo#Derived<int>#class_specialization#(3691368771332090182).157c4cba925bdfdc131986d2b52af05d_1" [label="1: Start class_specialization::Derived<int>::foo\nFormals: this:class_specialization::Derived<int>* t:int\nLocals: \n " color=yellow style=filled]
fix infinitely-expanding types in the backend Summary: Simple instance of the problem: analyzing the following program times out. ``` #include <tuple> void foo() { std::tuple<std::tuple<int>> x; } ``` Replacing `std::tuple<std::tuple<int>>` by `std::tuple<int>` makes the analysis terminate. In the AST, both tuple<tuple<int>> and tuple<int> have the same template specialization type: "Pack" (which means we're supposed to go look into the arguments of the template to get their values). This is not information enough and that's the plugin fault. On the backend side, this means that two types have the same Typ.Name.t, namely "std::tuple<_>", so they collide in the tenv. The definition of tuple<tuple<int>> is the one making it into the tenv. One of the fields of the corresponding CxxRecord is of type "tuple<int>", which we see as the same "tuple<_>", which causes the loop. update-submodule: facebook-clang-plugins Reviewed By: mbouaziz Differential Revision: D5775840 fbshipit-source-id: 0528604
7 years ago
[clang] update clang plugin to hash mangled names Summary: With this change and the previous facebook-clang-plugins change, infer no longer exhausts the biniou buffer when reading the serialized C++ AST. update-submodule: facebook-clang-plugins Reviewed By: mbouaziz Differential Revision: D5891081 fbshipit-source-id: cf48eac
7 years ago
"foo#Derived<int>#class_specialization#(3691368771332090182).157c4cba925bdfdc131986d2b52af05d_1" -> "foo#Derived<int>#class_specialization#(3691368771332090182).157c4cba925bdfdc131986d2b52af05d_3" ;
RFC: stop using _ to separate ObjC/C++ class name from method in Typ.Procname.to_string Reviewed By: jvillard Differential Revision: D14736442 fbshipit-source-id: 500df354b
6 years ago
"foo#Derived<int>#class_specialization#(3691368771332090182).157c4cba925bdfdc131986d2b52af05d_2" [label="2: Exit class_specialization::Derived<int>::foo \n " color=yellow style=filled]
fix infinitely-expanding types in the backend Summary: Simple instance of the problem: analyzing the following program times out. ``` #include <tuple> void foo() { std::tuple<std::tuple<int>> x; } ``` Replacing `std::tuple<std::tuple<int>>` by `std::tuple<int>` makes the analysis terminate. In the AST, both tuple<tuple<int>> and tuple<int> have the same template specialization type: "Pack" (which means we're supposed to go look into the arguments of the template to get their values). This is not information enough and that's the plugin fault. On the backend side, this means that two types have the same Typ.Name.t, namely "std::tuple<_>", so they collide in the tenv. The definition of tuple<tuple<int>> is the one making it into the tenv. One of the fields of the corresponding CxxRecord is of type "tuple<int>", which we see as the same "tuple<_>", which causes the loop. update-submodule: facebook-clang-plugins Reviewed By: mbouaziz Differential Revision: D5775840 fbshipit-source-id: 0528604
7 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
"foo#Derived<int>#class_specialization#(3691368771332090182).157c4cba925bdfdc131986d2b52af05d_3" [label="3: BinaryOperatorStmt: Assign \n n$0=*&this:class_specialization::Derived<int>* [line 16, column 19]\n n$1=*&t:int [line 16, column 29]\n *n$0.x:int=n$1 [line 16, column 19]\n " shape="box"]
fix infinitely-expanding types in the backend Summary: Simple instance of the problem: analyzing the following program times out. ``` #include <tuple> void foo() { std::tuple<std::tuple<int>> x; } ``` Replacing `std::tuple<std::tuple<int>>` by `std::tuple<int>` makes the analysis terminate. In the AST, both tuple<tuple<int>> and tuple<int> have the same template specialization type: "Pack" (which means we're supposed to go look into the arguments of the template to get their values). This is not information enough and that's the plugin fault. On the backend side, this means that two types have the same Typ.Name.t, namely "std::tuple<_>", so they collide in the tenv. The definition of tuple<tuple<int>> is the one making it into the tenv. One of the fields of the corresponding CxxRecord is of type "tuple<int>", which we see as the same "tuple<_>", which causes the loop. update-submodule: facebook-clang-plugins Reviewed By: mbouaziz Differential Revision: D5775840 fbshipit-source-id: 0528604
7 years ago
[clang] update clang plugin to hash mangled names Summary: With this change and the previous facebook-clang-plugins change, infer no longer exhausts the biniou buffer when reading the serialized C++ AST. update-submodule: facebook-clang-plugins Reviewed By: mbouaziz Differential Revision: D5891081 fbshipit-source-id: cf48eac
7 years ago
"foo#Derived<int>#class_specialization#(3691368771332090182).157c4cba925bdfdc131986d2b52af05d_3" -> "foo#Derived<int>#class_specialization#(3691368771332090182).157c4cba925bdfdc131986d2b52af05d_2" ;
RFC: stop using _ to separate ObjC/C++ class name from method in Typ.Procname.to_string Reviewed By: jvillard Differential Revision: D14736442 fbshipit-source-id: 500df354b
6 years ago
"Derived#Derived<int>#class_specialization#{14157761386473130888}.40e79d469e516a33fdff720996ff80ab_1" [label="1: Start class_specialization::Derived<int>::Derived\nFormals: this:class_specialization::Derived<int>*\nLocals: \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
[clang] Adding parameters as part of the procname for C++/ObjC methods and ObjC blocks Reviewed By: mbouaziz Differential Revision: D8237112 fbshipit-source-id: c0ec4b4
7 years ago
"Derived#Derived<int>#class_specialization#{14157761386473130888}.40e79d469e516a33fdff720996ff80ab_1" -> "Derived#Derived<int>#class_specialization#{14157761386473130888}.40e79d469e516a33fdff720996ff80ab_3" ;
RFC: stop using _ to separate ObjC/C++ class name from method in Typ.Procname.to_string Reviewed By: jvillard Differential Revision: D14736442 fbshipit-source-id: 500df354b
6 years ago
"Derived#Derived<int>#class_specialization#{14157761386473130888}.40e79d469e516a33fdff720996ff80ab_2" [label="2: Exit class_specialization::Derived<int>::Derived \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
[clang] fix order of translation for [this] Summary: We need to make sure a node is created to avoid instructions appearing in the wrong order in the final CFG. Reviewed By: da319 Differential Revision: D25784405 fbshipit-source-id: 3ef27d712
4 years ago
"Derived#Derived<int>#class_specialization#{14157761386473130888}.40e79d469e516a33fdff720996ff80ab_3" [label="3: Constructor Init \n n$1=*&this:class_specialization::Derived<int>* [line 15, column 8]\n " shape="box"]
"Derived#Derived<int>#class_specialization#{14157761386473130888}.40e79d469e516a33fdff720996ff80ab_3" -> "Derived#Derived<int>#class_specialization#{14157761386473130888}.40e79d469e516a33fdff720996ff80ab_4" ;
"Derived#Derived<int>#class_specialization#{14157761386473130888}.40e79d469e516a33fdff720996ff80ab_4" [label="4: Constructor Init \n n$2=_fun_class_specialization::Base<int>::Base(n$1:class_specialization::Derived<int>*) [line 15, column 8]\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
[clang] fix order of translation for [this] Summary: We need to make sure a node is created to avoid instructions appearing in the wrong order in the final CFG. Reviewed By: da319 Differential Revision: D25784405 fbshipit-source-id: 3ef27d712
4 years ago
"Derived#Derived<int>#class_specialization#{14157761386473130888}.40e79d469e516a33fdff720996ff80ab_4" -> "Derived#Derived<int>#class_specialization#{14157761386473130888}.40e79d469e516a33fdff720996ff80ab_2" ;
[C++] update fcp to deal with template specializations Summary: Update facebook-clang-plugins to fetch the fix of template arguments of template specialized classes. update-submodule: facebook-clang-plugins Reviewed By: grievejia Differential Revision: D5582942 fbshipit-source-id: b6d2efe
7 years ago
}