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 'c5cbd3142e'
${ noResults }
infer_clone/infer/tests/codetoanalyze/cpp/shared/conditional/binary_conditional.cpp.dot

200 lines
23 KiB
Raw Normal View History Unescape

[tests] Clean up test files shared between frontend and endtoend tests Reviewed By: jberdine Differential Revision: D3893900 fbshipit-source-id: 497effc
8 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 {
[clang] fix bad interaction between ConditionalOperator and initializers Summary: This is several inter-connected changes together to keep the tests happy. The ConditionalOperator `b?t:e` is translated by first creating a placeholder variable to temporarily store the result of the evaluation in each branch, then the real thing we want to assign to reads that variable. But, there are situations where that changes the semantics of the expression, namely when the value created is a struct on the stack (eg, a C++ temporary). This is because in SIL we cannot assign the *address* of a program variable, only its contents, so by the time we're out of the conditional operator we cannot set the struct value correctly anymore: we can only set its content, which we did, but that results in a "shifted" struct value that is one dereference away from where it should be. So a batch of changes concern `conditionalOperator_trans`: - instead of systematically creating a temporary for the conditional, use the `trans_state.var_exp_typ` provided from above if available when translating `ConditionalOperator` - don't even set anything if that variable was already initialized by merely translating the branch expression, eg when it's a constructor - fix long-standing TODO to propagate these initialization facts accurately for ConditionalOperator (used by `init_expr_trans` to also figure out if it should insert a store to the variable being initialised or not) The rest of the changes adapt some relevant other constructs to deal with conditionalOperator properly now that it can set the current variable itself, instead of storing stuff inside a temp variable. This change was a problem because some constructs, eg a variable declaration, will insert nodes that set up the variable before calling its initialization, and now the initialization happens *before* that setup, in the translation of the inner conditional operator, which naturally creates nodes above the current one. - add a generic helper to force a sequential order between two translation results, forcing node creation if necessary - use that in `init_expr_trans` and `cxxNewExpr_trans` - adjust many places where `var_exp_typ` was incorrectly not reset when translating sub-expressions The sequentiality business creates more nodes when used, and the conditionalOperator business uses fewer temporary variables, so the frontend results change quite a bit. Note that biabduction tests were invaluable in debugging this. There could be other constructs to adjust similarly to cxxNewExpr that were not covered by the tests though. Added tests in pulse that exercises the previous bug. Reviewed By: da319 Differential Revision: D24796282 fbshipit-source-id: 0790c8d17
4 years ago
"binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_1" [label="1: Start binary_conditional::binaryConditional\nFormals: \nLocals: x:binary_conditional::X 0$?%__sil_tmpSIL_materialize_temp__n$6:binary_conditional::X 0$?%__sil_tmpSIL_materialize_temp__n$5:binary_conditional::X a:binary_conditional::X \n " color=yellow style=filled]
[tests] Clean up test files shared between frontend and endtoend tests Reviewed By: jberdine Differential Revision: D3893900 fbshipit-source-id: 497effc
8 years ago
[clang] fix bad interaction between ConditionalOperator and initializers Summary: This is several inter-connected changes together to keep the tests happy. The ConditionalOperator `b?t:e` is translated by first creating a placeholder variable to temporarily store the result of the evaluation in each branch, then the real thing we want to assign to reads that variable. But, there are situations where that changes the semantics of the expression, namely when the value created is a struct on the stack (eg, a C++ temporary). This is because in SIL we cannot assign the *address* of a program variable, only its contents, so by the time we're out of the conditional operator we cannot set the struct value correctly anymore: we can only set its content, which we did, but that results in a "shifted" struct value that is one dereference away from where it should be. So a batch of changes concern `conditionalOperator_trans`: - instead of systematically creating a temporary for the conditional, use the `trans_state.var_exp_typ` provided from above if available when translating `ConditionalOperator` - don't even set anything if that variable was already initialized by merely translating the branch expression, eg when it's a constructor - fix long-standing TODO to propagate these initialization facts accurately for ConditionalOperator (used by `init_expr_trans` to also figure out if it should insert a store to the variable being initialised or not) The rest of the changes adapt some relevant other constructs to deal with conditionalOperator properly now that it can set the current variable itself, instead of storing stuff inside a temp variable. This change was a problem because some constructs, eg a variable declaration, will insert nodes that set up the variable before calling its initialization, and now the initialization happens *before* that setup, in the translation of the inner conditional operator, which naturally creates nodes above the current one. - add a generic helper to force a sequential order between two translation results, forcing node creation if necessary - use that in `init_expr_trans` and `cxxNewExpr_trans` - adjust many places where `var_exp_typ` was incorrectly not reset when translating sub-expressions The sequentiality business creates more nodes when used, and the conditionalOperator business uses fewer temporary variables, so the frontend results change quite a bit. Note that biabduction tests were invaluable in debugging this. There could be other constructs to adjust similarly to cxxNewExpr that were not covered by the tests though. Added tests in pulse that exercises the previous bug. Reviewed By: da319 Differential Revision: D24796282 fbshipit-source-id: 0790c8d17
4 years ago
"binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_1" -> "binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_14" ;
[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
"binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_2" [label="2: Exit binary_conditional::binaryConditional \n " color=yellow style=filled]
[tests] Clean up test files shared between frontend and endtoend tests Reviewed By: jberdine Differential Revision: D3893900 fbshipit-source-id: 497effc
8 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
"binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_3" [label="3: Destruction(Scope) \n _=*&x:binary_conditional::X [line 23, column 1]\n n$1=_fun_binary_conditional::X::~X(&x:binary_conditional::X*) injected [line 23, column 1]\n _=*&a:binary_conditional::X [line 23, column 1]\n n$3=_fun_binary_conditional::X::~X(&a:binary_conditional::X*) injected [line 23, column 1]\n " shape="box"]
[tests] Clean up test files shared between frontend and endtoend tests Reviewed By: jberdine Differential Revision: D3893900 fbshipit-source-id: 497effc
8 years ago
[destructors] Inject destructor calls even if the destructor declaration is empty Summary: We do not inject a destructor call if the destructor declaration does not contain a body in AST. We miss all the cases where the destructor is declared in `.h` file and defined in `.cpp` file as other files include `.h` file and do not contain the body of the destructor when destructor calls are being injected based on AST information. After this diff we inject destructor calls even if we do not have body for the destructor in AST. Reviewed By: sblackshear Differential Revision: D6796567 fbshipit-source-id: 1c187ec
7 years ago
"binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_3" -> "binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_2" ;
[clang] deal with conditionally-destroyed temporaries Summary: This was left as a TODO before: where to place calls to destructors for C++ temporaries that are only conditionally creating when evaluating an expression. This can happen inside the branches of a conditional operation `b?e:f` or in potentially-short-circuited conditions on the righ-hand side of `&&` and `||` operators. Following the compilation scheme of clang (observed by looking at the generated LLVM bitcode), we instrument the program with "marker" variables, so that for instance `X x = true?X():y;` becomes (following the execution on the true branch): ``` marker1 = 0; // initialize all markers to 0 PRUNE(true) // entering true branch X::X(&temporary); // create temporary... marker1 = 1; // ...triggers setting its marker to 1 X::X(&x, &temporary); // finish expression if (marker1) { X::~X(&temporary); // conditionally destroy the temporary } ``` In this diff, you'll find code for: - associating markers to temporaries that need them - code to initialize markers to 0 before full-expressions - code to conditionally destroy temporaries based on the values of the markers once the full-expression has finished evaluating Reviewed By: da319 Differential Revision: D24954070 fbshipit-source-id: cf15df7f7
4 years ago
"binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_4" [label="4: DeclStmt \n VARIABLE_DECLARED(0$?%__sil_tmpSIL_materialize_temp__n$6:binary_conditional::X); [line 22, column 9]\n n$8=_fun_binary_conditional::getX(&0$?%__sil_tmpSIL_materialize_temp__n$6:binary_conditional::X*) assign_last [line 22, column 9]\n " shape="box"]
[tests] Clean up test files shared between frontend and endtoend tests Reviewed By: jberdine Differential Revision: D3893900 fbshipit-source-id: 497effc
8 years ago
[clang] fix bad interaction between ConditionalOperator and initializers Summary: This is several inter-connected changes together to keep the tests happy. The ConditionalOperator `b?t:e` is translated by first creating a placeholder variable to temporarily store the result of the evaluation in each branch, then the real thing we want to assign to reads that variable. But, there are situations where that changes the semantics of the expression, namely when the value created is a struct on the stack (eg, a C++ temporary). This is because in SIL we cannot assign the *address* of a program variable, only its contents, so by the time we're out of the conditional operator we cannot set the struct value correctly anymore: we can only set its content, which we did, but that results in a "shifted" struct value that is one dereference away from where it should be. So a batch of changes concern `conditionalOperator_trans`: - instead of systematically creating a temporary for the conditional, use the `trans_state.var_exp_typ` provided from above if available when translating `ConditionalOperator` - don't even set anything if that variable was already initialized by merely translating the branch expression, eg when it's a constructor - fix long-standing TODO to propagate these initialization facts accurately for ConditionalOperator (used by `init_expr_trans` to also figure out if it should insert a store to the variable being initialised or not) The rest of the changes adapt some relevant other constructs to deal with conditionalOperator properly now that it can set the current variable itself, instead of storing stuff inside a temp variable. This change was a problem because some constructs, eg a variable declaration, will insert nodes that set up the variable before calling its initialization, and now the initialization happens *before* that setup, in the translation of the inner conditional operator, which naturally creates nodes above the current one. - add a generic helper to force a sequential order between two translation results, forcing node creation if necessary - use that in `init_expr_trans` and `cxxNewExpr_trans` - adjust many places where `var_exp_typ` was incorrectly not reset when translating sub-expressions The sequentiality business creates more nodes when used, and the conditionalOperator business uses fewer temporary variables, so the frontend results change quite a bit. Note that biabduction tests were invaluable in debugging this. There could be other constructs to adjust similarly to cxxNewExpr that were not covered by the tests though. Added tests in pulse that exercises the previous bug. Reviewed By: da319 Differential Revision: D24796282 fbshipit-source-id: 0790c8d17
4 years ago
"binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_4" -> "binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_6" ;
"binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_5" [label="5: + \n " ]
[tests] Clean up test files shared between frontend and endtoend tests Reviewed By: jberdine Differential Revision: D3893900 fbshipit-source-id: 497effc
8 years ago
[clang] deal with conditionally-destroyed temporaries Summary: This was left as a TODO before: where to place calls to destructors for C++ temporaries that are only conditionally creating when evaluating an expression. This can happen inside the branches of a conditional operation `b?e:f` or in potentially-short-circuited conditions on the righ-hand side of `&&` and `||` operators. Following the compilation scheme of clang (observed by looking at the generated LLVM bitcode), we instrument the program with "marker" variables, so that for instance `X x = true?X():y;` becomes (following the execution on the true branch): ``` marker1 = 0; // initialize all markers to 0 PRUNE(true) // entering true branch X::X(&temporary); // create temporary... marker1 = 1; // ...triggers setting its marker to 1 X::X(&x, &temporary); // finish expression if (marker1) { X::~X(&temporary); // conditionally destroy the temporary } ``` In this diff, you'll find code for: - associating markers to temporaries that need them - code to initialize markers to 0 before full-expressions - code to conditionally destroy temporaries based on the values of the markers once the full-expression has finished evaluating Reviewed By: da319 Differential Revision: D24954070 fbshipit-source-id: cf15df7f7
4 years ago
"binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_5" -> "binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_12" ;
"binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_6" [label="6: Call _fun_binary_conditional::X::operator_bool \n _=*&0$?%__sil_tmpSIL_materialize_temp__n$6:binary_conditional::X [line 22, column 9]\n n$10=_fun_binary_conditional::X::operator_bool(&0$?%__sil_tmpSIL_materialize_temp__n$6:binary_conditional::X&) [line 22, column 9]\n " shape="box"]
[tests] Clean up test files shared between frontend and endtoend tests Reviewed By: jberdine Differential Revision: D3893900 fbshipit-source-id: 497effc
8 years ago
[clang] fix bad interaction between ConditionalOperator and initializers Summary: This is several inter-connected changes together to keep the tests happy. The ConditionalOperator `b?t:e` is translated by first creating a placeholder variable to temporarily store the result of the evaluation in each branch, then the real thing we want to assign to reads that variable. But, there are situations where that changes the semantics of the expression, namely when the value created is a struct on the stack (eg, a C++ temporary). This is because in SIL we cannot assign the *address* of a program variable, only its contents, so by the time we're out of the conditional operator we cannot set the struct value correctly anymore: we can only set its content, which we did, but that results in a "shifted" struct value that is one dereference away from where it should be. So a batch of changes concern `conditionalOperator_trans`: - instead of systematically creating a temporary for the conditional, use the `trans_state.var_exp_typ` provided from above if available when translating `ConditionalOperator` - don't even set anything if that variable was already initialized by merely translating the branch expression, eg when it's a constructor - fix long-standing TODO to propagate these initialization facts accurately for ConditionalOperator (used by `init_expr_trans` to also figure out if it should insert a store to the variable being initialised or not) The rest of the changes adapt some relevant other constructs to deal with conditionalOperator properly now that it can set the current variable itself, instead of storing stuff inside a temp variable. This change was a problem because some constructs, eg a variable declaration, will insert nodes that set up the variable before calling its initialization, and now the initialization happens *before* that setup, in the translation of the inner conditional operator, which naturally creates nodes above the current one. - add a generic helper to force a sequential order between two translation results, forcing node creation if necessary - use that in `init_expr_trans` and `cxxNewExpr_trans` - adjust many places where `var_exp_typ` was incorrectly not reset when translating sub-expressions The sequentiality business creates more nodes when used, and the conditionalOperator business uses fewer temporary variables, so the frontend results change quite a bit. Note that biabduction tests were invaluable in debugging this. There could be other constructs to adjust similarly to cxxNewExpr that were not covered by the tests though. Added tests in pulse that exercises the previous bug. Reviewed By: da319 Differential Revision: D24796282 fbshipit-source-id: 0790c8d17
4 years ago
"binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_6" -> "binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_7" ;
[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
"binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_6" -> "binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_8" ;
[clang] deal with conditionally-destroyed temporaries Summary: This was left as a TODO before: where to place calls to destructors for C++ temporaries that are only conditionally creating when evaluating an expression. This can happen inside the branches of a conditional operation `b?e:f` or in potentially-short-circuited conditions on the righ-hand side of `&&` and `||` operators. Following the compilation scheme of clang (observed by looking at the generated LLVM bitcode), we instrument the program with "marker" variables, so that for instance `X x = true?X():y;` becomes (following the execution on the true branch): ``` marker1 = 0; // initialize all markers to 0 PRUNE(true) // entering true branch X::X(&temporary); // create temporary... marker1 = 1; // ...triggers setting its marker to 1 X::X(&x, &temporary); // finish expression if (marker1) { X::~X(&temporary); // conditionally destroy the temporary } ``` In this diff, you'll find code for: - associating markers to temporaries that need them - code to initialize markers to 0 before full-expressions - code to conditionally destroy temporaries based on the values of the markers once the full-expression has finished evaluating Reviewed By: da319 Differential Revision: D24954070 fbshipit-source-id: cf15df7f7
4 years ago
"binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_7" [label="7: Prune (true branch, boolean exp) \n PRUNE(n$10, true); [line 22, column 9]\n " shape="invhouse"]
[tests] Clean up test files shared between frontend and endtoend tests Reviewed By: jberdine Differential Revision: D3893900 fbshipit-source-id: 497effc
8 years ago
[destructors] Inject destructor calls even if the destructor declaration is empty Summary: We do not inject a destructor call if the destructor declaration does not contain a body in AST. We miss all the cases where the destructor is declared in `.h` file and defined in `.cpp` file as other files include `.h` file and do not contain the body of the destructor when destructor calls are being injected based on AST information. After this diff we inject destructor calls even if we do not have body for the destructor in AST. Reviewed By: sblackshear Differential Revision: D6796567 fbshipit-source-id: 1c187ec
7 years ago
"binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_7" -> "binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_9" ;
[clang] deal with conditionally-destroyed temporaries Summary: This was left as a TODO before: where to place calls to destructors for C++ temporaries that are only conditionally creating when evaluating an expression. This can happen inside the branches of a conditional operation `b?e:f` or in potentially-short-circuited conditions on the righ-hand side of `&&` and `||` operators. Following the compilation scheme of clang (observed by looking at the generated LLVM bitcode), we instrument the program with "marker" variables, so that for instance `X x = true?X():y;` becomes (following the execution on the true branch): ``` marker1 = 0; // initialize all markers to 0 PRUNE(true) // entering true branch X::X(&temporary); // create temporary... marker1 = 1; // ...triggers setting its marker to 1 X::X(&x, &temporary); // finish expression if (marker1) { X::~X(&temporary); // conditionally destroy the temporary } ``` In this diff, you'll find code for: - associating markers to temporaries that need them - code to initialize markers to 0 before full-expressions - code to conditionally destroy temporaries based on the values of the markers once the full-expression has finished evaluating Reviewed By: da319 Differential Revision: D24954070 fbshipit-source-id: cf15df7f7
4 years ago
"binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_8" [label="8: Prune (false branch, boolean exp) \n PRUNE(!n$10, false); [line 22, column 9]\n " shape="invhouse"]
[tests] Clean up test files shared between frontend and endtoend tests Reviewed By: jberdine Differential Revision: D3893900 fbshipit-source-id: 497effc
8 years ago
[clang] fix bad interaction between ConditionalOperator and initializers Summary: This is several inter-connected changes together to keep the tests happy. The ConditionalOperator `b?t:e` is translated by first creating a placeholder variable to temporarily store the result of the evaluation in each branch, then the real thing we want to assign to reads that variable. But, there are situations where that changes the semantics of the expression, namely when the value created is a struct on the stack (eg, a C++ temporary). This is because in SIL we cannot assign the *address* of a program variable, only its contents, so by the time we're out of the conditional operator we cannot set the struct value correctly anymore: we can only set its content, which we did, but that results in a "shifted" struct value that is one dereference away from where it should be. So a batch of changes concern `conditionalOperator_trans`: - instead of systematically creating a temporary for the conditional, use the `trans_state.var_exp_typ` provided from above if available when translating `ConditionalOperator` - don't even set anything if that variable was already initialized by merely translating the branch expression, eg when it's a constructor - fix long-standing TODO to propagate these initialization facts accurately for ConditionalOperator (used by `init_expr_trans` to also figure out if it should insert a store to the variable being initialised or not) The rest of the changes adapt some relevant other constructs to deal with conditionalOperator properly now that it can set the current variable itself, instead of storing stuff inside a temp variable. This change was a problem because some constructs, eg a variable declaration, will insert nodes that set up the variable before calling its initialization, and now the initialization happens *before* that setup, in the translation of the inner conditional operator, which naturally creates nodes above the current one. - add a generic helper to force a sequential order between two translation results, forcing node creation if necessary - use that in `init_expr_trans` and `cxxNewExpr_trans` - adjust many places where `var_exp_typ` was incorrectly not reset when translating sub-expressions The sequentiality business creates more nodes when used, and the conditionalOperator business uses fewer temporary variables, so the frontend results change quite a bit. Note that biabduction tests were invaluable in debugging this. There could be other constructs to adjust similarly to cxxNewExpr that were not covered by the tests though. Added tests in pulse that exercises the previous bug. Reviewed By: da319 Differential Revision: D24796282 fbshipit-source-id: 0790c8d17
4 years ago
"binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_8" -> "binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_10" ;
[clang] deal with conditionally-destroyed temporaries Summary: This was left as a TODO before: where to place calls to destructors for C++ temporaries that are only conditionally creating when evaluating an expression. This can happen inside the branches of a conditional operation `b?e:f` or in potentially-short-circuited conditions on the righ-hand side of `&&` and `||` operators. Following the compilation scheme of clang (observed by looking at the generated LLVM bitcode), we instrument the program with "marker" variables, so that for instance `X x = true?X():y;` becomes (following the execution on the true branch): ``` marker1 = 0; // initialize all markers to 0 PRUNE(true) // entering true branch X::X(&temporary); // create temporary... marker1 = 1; // ...triggers setting its marker to 1 X::X(&x, &temporary); // finish expression if (marker1) { X::~X(&temporary); // conditionally destroy the temporary } ``` In this diff, you'll find code for: - associating markers to temporaries that need them - code to initialize markers to 0 before full-expressions - code to conditionally destroy temporaries based on the values of the markers once the full-expression has finished evaluating Reviewed By: da319 Differential Revision: D24954070 fbshipit-source-id: cf15df7f7
4 years ago
"binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_9" [label="9: ConditionalStmt Branch \n n$11=_fun_binary_conditional::X::X(&0$?%__sil_tmpSIL_materialize_temp__n$5:binary_conditional::X*,&0$?%__sil_tmpSIL_materialize_temp__n$6:binary_conditional::X&) [line 22, column 9]\n " shape="box"]
[tests] Clean up test files shared between frontend and endtoend tests Reviewed By: jberdine Differential Revision: D3893900 fbshipit-source-id: 497effc
8 years ago
[clang] fix bad interaction between ConditionalOperator and initializers Summary: This is several inter-connected changes together to keep the tests happy. The ConditionalOperator `b?t:e` is translated by first creating a placeholder variable to temporarily store the result of the evaluation in each branch, then the real thing we want to assign to reads that variable. But, there are situations where that changes the semantics of the expression, namely when the value created is a struct on the stack (eg, a C++ temporary). This is because in SIL we cannot assign the *address* of a program variable, only its contents, so by the time we're out of the conditional operator we cannot set the struct value correctly anymore: we can only set its content, which we did, but that results in a "shifted" struct value that is one dereference away from where it should be. So a batch of changes concern `conditionalOperator_trans`: - instead of systematically creating a temporary for the conditional, use the `trans_state.var_exp_typ` provided from above if available when translating `ConditionalOperator` - don't even set anything if that variable was already initialized by merely translating the branch expression, eg when it's a constructor - fix long-standing TODO to propagate these initialization facts accurately for ConditionalOperator (used by `init_expr_trans` to also figure out if it should insert a store to the variable being initialised or not) The rest of the changes adapt some relevant other constructs to deal with conditionalOperator properly now that it can set the current variable itself, instead of storing stuff inside a temp variable. This change was a problem because some constructs, eg a variable declaration, will insert nodes that set up the variable before calling its initialization, and now the initialization happens *before* that setup, in the translation of the inner conditional operator, which naturally creates nodes above the current one. - add a generic helper to force a sequential order between two translation results, forcing node creation if necessary - use that in `init_expr_trans` and `cxxNewExpr_trans` - adjust many places where `var_exp_typ` was incorrectly not reset when translating sub-expressions The sequentiality business creates more nodes when used, and the conditionalOperator business uses fewer temporary variables, so the frontend results change quite a bit. Note that biabduction tests were invaluable in debugging this. There could be other constructs to adjust similarly to cxxNewExpr that were not covered by the tests though. Added tests in pulse that exercises the previous bug. Reviewed By: da319 Differential Revision: D24796282 fbshipit-source-id: 0790c8d17
4 years ago
"binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_9" -> "binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_5" ;
[clang] deal with conditionally-destroyed temporaries Summary: This was left as a TODO before: where to place calls to destructors for C++ temporaries that are only conditionally creating when evaluating an expression. This can happen inside the branches of a conditional operation `b?e:f` or in potentially-short-circuited conditions on the righ-hand side of `&&` and `||` operators. Following the compilation scheme of clang (observed by looking at the generated LLVM bitcode), we instrument the program with "marker" variables, so that for instance `X x = true?X():y;` becomes (following the execution on the true branch): ``` marker1 = 0; // initialize all markers to 0 PRUNE(true) // entering true branch X::X(&temporary); // create temporary... marker1 = 1; // ...triggers setting its marker to 1 X::X(&x, &temporary); // finish expression if (marker1) { X::~X(&temporary); // conditionally destroy the temporary } ``` In this diff, you'll find code for: - associating markers to temporaries that need them - code to initialize markers to 0 before full-expressions - code to conditionally destroy temporaries based on the values of the markers once the full-expression has finished evaluating Reviewed By: da319 Differential Revision: D24954070 fbshipit-source-id: cf15df7f7
4 years ago
"binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_10" [label="10: ConditionalStmt Branch \n n$12=_fun_binary_conditional::X::X(&0$?%__sil_tmpSIL_materialize_temp__n$5:binary_conditional::X*,&a:binary_conditional::X&) [line 22, column 19]\n " shape="box"]
[tests] Clean up test files shared between frontend and endtoend tests Reviewed By: jberdine Differential Revision: D3893900 fbshipit-source-id: 497effc
8 years ago
[destructors] Inject destructor calls even if the destructor declaration is empty Summary: We do not inject a destructor call if the destructor declaration does not contain a body in AST. We miss all the cases where the destructor is declared in `.h` file and defined in `.cpp` file as other files include `.h` file and do not contain the body of the destructor when destructor calls are being injected based on AST information. After this diff we inject destructor calls even if we do not have body for the destructor in AST. Reviewed By: sblackshear Differential Revision: D6796567 fbshipit-source-id: 1c187ec
7 years ago
"binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_10" -> "binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_5" ;
[clang] fix bad interaction between ConditionalOperator and initializers Summary: This is several inter-connected changes together to keep the tests happy. The ConditionalOperator `b?t:e` is translated by first creating a placeholder variable to temporarily store the result of the evaluation in each branch, then the real thing we want to assign to reads that variable. But, there are situations where that changes the semantics of the expression, namely when the value created is a struct on the stack (eg, a C++ temporary). This is because in SIL we cannot assign the *address* of a program variable, only its contents, so by the time we're out of the conditional operator we cannot set the struct value correctly anymore: we can only set its content, which we did, but that results in a "shifted" struct value that is one dereference away from where it should be. So a batch of changes concern `conditionalOperator_trans`: - instead of systematically creating a temporary for the conditional, use the `trans_state.var_exp_typ` provided from above if available when translating `ConditionalOperator` - don't even set anything if that variable was already initialized by merely translating the branch expression, eg when it's a constructor - fix long-standing TODO to propagate these initialization facts accurately for ConditionalOperator (used by `init_expr_trans` to also figure out if it should insert a store to the variable being initialised or not) The rest of the changes adapt some relevant other constructs to deal with conditionalOperator properly now that it can set the current variable itself, instead of storing stuff inside a temp variable. This change was a problem because some constructs, eg a variable declaration, will insert nodes that set up the variable before calling its initialization, and now the initialization happens *before* that setup, in the translation of the inner conditional operator, which naturally creates nodes above the current one. - add a generic helper to force a sequential order between two translation results, forcing node creation if necessary - use that in `init_expr_trans` and `cxxNewExpr_trans` - adjust many places where `var_exp_typ` was incorrectly not reset when translating sub-expressions The sequentiality business creates more nodes when used, and the conditionalOperator business uses fewer temporary variables, so the frontend results change quite a bit. Note that biabduction tests were invaluable in debugging this. There could be other constructs to adjust similarly to cxxNewExpr that were not covered by the tests though. Added tests in pulse that exercises the previous bug. Reviewed By: da319 Differential Revision: D24796282 fbshipit-source-id: 0790c8d17
4 years ago
"binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_11" [label="11: DeclStmt \n VARIABLE_DECLARED(0$?%__sil_tmpSIL_materialize_temp__n$5:binary_conditional::X); [line 22, column 9]\n " shape="box"]
[tests] Clean up test files shared between frontend and endtoend tests Reviewed By: jberdine Differential Revision: D3893900 fbshipit-source-id: 497effc
8 years ago
[clang] fix bad interaction between ConditionalOperator and initializers Summary: This is several inter-connected changes together to keep the tests happy. The ConditionalOperator `b?t:e` is translated by first creating a placeholder variable to temporarily store the result of the evaluation in each branch, then the real thing we want to assign to reads that variable. But, there are situations where that changes the semantics of the expression, namely when the value created is a struct on the stack (eg, a C++ temporary). This is because in SIL we cannot assign the *address* of a program variable, only its contents, so by the time we're out of the conditional operator we cannot set the struct value correctly anymore: we can only set its content, which we did, but that results in a "shifted" struct value that is one dereference away from where it should be. So a batch of changes concern `conditionalOperator_trans`: - instead of systematically creating a temporary for the conditional, use the `trans_state.var_exp_typ` provided from above if available when translating `ConditionalOperator` - don't even set anything if that variable was already initialized by merely translating the branch expression, eg when it's a constructor - fix long-standing TODO to propagate these initialization facts accurately for ConditionalOperator (used by `init_expr_trans` to also figure out if it should insert a store to the variable being initialised or not) The rest of the changes adapt some relevant other constructs to deal with conditionalOperator properly now that it can set the current variable itself, instead of storing stuff inside a temp variable. This change was a problem because some constructs, eg a variable declaration, will insert nodes that set up the variable before calling its initialization, and now the initialization happens *before* that setup, in the translation of the inner conditional operator, which naturally creates nodes above the current one. - add a generic helper to force a sequential order between two translation results, forcing node creation if necessary - use that in `init_expr_trans` and `cxxNewExpr_trans` - adjust many places where `var_exp_typ` was incorrectly not reset when translating sub-expressions The sequentiality business creates more nodes when used, and the conditionalOperator business uses fewer temporary variables, so the frontend results change quite a bit. Note that biabduction tests were invaluable in debugging this. There could be other constructs to adjust similarly to cxxNewExpr that were not covered by the tests though. Added tests in pulse that exercises the previous bug. Reviewed By: da319 Differential Revision: D24796282 fbshipit-source-id: 0790c8d17
4 years ago
"binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_11" -> "binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_4" ;
[clang] deal with conditionally-destroyed temporaries Summary: This was left as a TODO before: where to place calls to destructors for C++ temporaries that are only conditionally creating when evaluating an expression. This can happen inside the branches of a conditional operation `b?e:f` or in potentially-short-circuited conditions on the righ-hand side of `&&` and `||` operators. Following the compilation scheme of clang (observed by looking at the generated LLVM bitcode), we instrument the program with "marker" variables, so that for instance `X x = true?X():y;` becomes (following the execution on the true branch): ``` marker1 = 0; // initialize all markers to 0 PRUNE(true) // entering true branch X::X(&temporary); // create temporary... marker1 = 1; // ...triggers setting its marker to 1 X::X(&x, &temporary); // finish expression if (marker1) { X::~X(&temporary); // conditionally destroy the temporary } ``` In this diff, you'll find code for: - associating markers to temporaries that need them - code to initialize markers to 0 before full-expressions - code to conditionally destroy temporaries based on the values of the markers once the full-expression has finished evaluating Reviewed By: da319 Differential Revision: D24954070 fbshipit-source-id: cf15df7f7
4 years ago
"binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_12" [label="12: Destruction(temporaries cleanup) \n n$13=_fun_binary_conditional::X::X(&x:binary_conditional::X*,&0$?%__sil_tmpSIL_materialize_temp__n$5:binary_conditional::X&) [line 22, column 9]\n _=*&0$?%__sil_tmpSIL_materialize_temp__n$6:binary_conditional::X [line 22, column 19]\n n$17=_fun_binary_conditional::X::~X(&0$?%__sil_tmpSIL_materialize_temp__n$6:binary_conditional::X*) injected [line 22, column 19]\n _=*&0$?%__sil_tmpSIL_materialize_temp__n$5:binary_conditional::X [line 22, column 19]\n n$15=_fun_binary_conditional::X::~X(&0$?%__sil_tmpSIL_materialize_temp__n$5:binary_conditional::X*) injected [line 22, column 19]\n " shape="box"]
[tests] Clean up test files shared between frontend and endtoend tests Reviewed By: jberdine Differential Revision: D3893900 fbshipit-source-id: 497effc
8 years ago
[clang] deal with conditionally-destroyed temporaries Summary: This was left as a TODO before: where to place calls to destructors for C++ temporaries that are only conditionally creating when evaluating an expression. This can happen inside the branches of a conditional operation `b?e:f` or in potentially-short-circuited conditions on the righ-hand side of `&&` and `||` operators. Following the compilation scheme of clang (observed by looking at the generated LLVM bitcode), we instrument the program with "marker" variables, so that for instance `X x = true?X():y;` becomes (following the execution on the true branch): ``` marker1 = 0; // initialize all markers to 0 PRUNE(true) // entering true branch X::X(&temporary); // create temporary... marker1 = 1; // ...triggers setting its marker to 1 X::X(&x, &temporary); // finish expression if (marker1) { X::~X(&temporary); // conditionally destroy the temporary } ``` In this diff, you'll find code for: - associating markers to temporaries that need them - code to initialize markers to 0 before full-expressions - code to conditionally destroy temporaries based on the values of the markers once the full-expression has finished evaluating Reviewed By: da319 Differential Revision: D24954070 fbshipit-source-id: cf15df7f7
4 years ago
"binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_12" -> "binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_3" ;
"binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_13" [label="13: DeclStmt \n VARIABLE_DECLARED(x:binary_conditional::X); [line 22, column 3]\n " shape="box"]
[destructors] Inject destructor calls even if the destructor declaration is empty Summary: We do not inject a destructor call if the destructor declaration does not contain a body in AST. We miss all the cases where the destructor is declared in `.h` file and defined in `.cpp` file as other files include `.h` file and do not contain the body of the destructor when destructor calls are being injected based on AST information. After this diff we inject destructor calls even if we do not have body for the destructor in AST. Reviewed By: sblackshear Differential Revision: D6796567 fbshipit-source-id: 1c187ec
7 years ago
[clang] deal with conditionally-destroyed temporaries Summary: This was left as a TODO before: where to place calls to destructors for C++ temporaries that are only conditionally creating when evaluating an expression. This can happen inside the branches of a conditional operation `b?e:f` or in potentially-short-circuited conditions on the righ-hand side of `&&` and `||` operators. Following the compilation scheme of clang (observed by looking at the generated LLVM bitcode), we instrument the program with "marker" variables, so that for instance `X x = true?X():y;` becomes (following the execution on the true branch): ``` marker1 = 0; // initialize all markers to 0 PRUNE(true) // entering true branch X::X(&temporary); // create temporary... marker1 = 1; // ...triggers setting its marker to 1 X::X(&x, &temporary); // finish expression if (marker1) { X::~X(&temporary); // conditionally destroy the temporary } ``` In this diff, you'll find code for: - associating markers to temporaries that need them - code to initialize markers to 0 before full-expressions - code to conditionally destroy temporaries based on the values of the markers once the full-expression has finished evaluating Reviewed By: da319 Differential Revision: D24954070 fbshipit-source-id: cf15df7f7
4 years ago
"binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_13" -> "binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_11" ;
"binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_14" [label="14: DeclStmt \n VARIABLE_DECLARED(a:binary_conditional::X); [line 21, column 3]\n n$18=_fun_binary_conditional::X::X(&a:binary_conditional::X*) [line 21, column 5]\n " shape="box"]
[clang] fix bad interaction between ConditionalOperator and initializers Summary: This is several inter-connected changes together to keep the tests happy. The ConditionalOperator `b?t:e` is translated by first creating a placeholder variable to temporarily store the result of the evaluation in each branch, then the real thing we want to assign to reads that variable. But, there are situations where that changes the semantics of the expression, namely when the value created is a struct on the stack (eg, a C++ temporary). This is because in SIL we cannot assign the *address* of a program variable, only its contents, so by the time we're out of the conditional operator we cannot set the struct value correctly anymore: we can only set its content, which we did, but that results in a "shifted" struct value that is one dereference away from where it should be. So a batch of changes concern `conditionalOperator_trans`: - instead of systematically creating a temporary for the conditional, use the `trans_state.var_exp_typ` provided from above if available when translating `ConditionalOperator` - don't even set anything if that variable was already initialized by merely translating the branch expression, eg when it's a constructor - fix long-standing TODO to propagate these initialization facts accurately for ConditionalOperator (used by `init_expr_trans` to also figure out if it should insert a store to the variable being initialised or not) The rest of the changes adapt some relevant other constructs to deal with conditionalOperator properly now that it can set the current variable itself, instead of storing stuff inside a temp variable. This change was a problem because some constructs, eg a variable declaration, will insert nodes that set up the variable before calling its initialization, and now the initialization happens *before* that setup, in the translation of the inner conditional operator, which naturally creates nodes above the current one. - add a generic helper to force a sequential order between two translation results, forcing node creation if necessary - use that in `init_expr_trans` and `cxxNewExpr_trans` - adjust many places where `var_exp_typ` was incorrectly not reset when translating sub-expressions The sequentiality business creates more nodes when used, and the conditionalOperator business uses fewer temporary variables, so the frontend results change quite a bit. Note that biabduction tests were invaluable in debugging this. There could be other constructs to adjust similarly to cxxNewExpr that were not covered by the tests though. Added tests in pulse that exercises the previous bug. Reviewed By: da319 Differential Revision: D24796282 fbshipit-source-id: 0790c8d17
4 years ago
[clang] deal with conditionally-destroyed temporaries Summary: This was left as a TODO before: where to place calls to destructors for C++ temporaries that are only conditionally creating when evaluating an expression. This can happen inside the branches of a conditional operation `b?e:f` or in potentially-short-circuited conditions on the righ-hand side of `&&` and `||` operators. Following the compilation scheme of clang (observed by looking at the generated LLVM bitcode), we instrument the program with "marker" variables, so that for instance `X x = true?X():y;` becomes (following the execution on the true branch): ``` marker1 = 0; // initialize all markers to 0 PRUNE(true) // entering true branch X::X(&temporary); // create temporary... marker1 = 1; // ...triggers setting its marker to 1 X::X(&x, &temporary); // finish expression if (marker1) { X::~X(&temporary); // conditionally destroy the temporary } ``` In this diff, you'll find code for: - associating markers to temporaries that need them - code to initialize markers to 0 before full-expressions - code to conditionally destroy temporaries based on the values of the markers once the full-expression has finished evaluating Reviewed By: da319 Differential Revision: D24954070 fbshipit-source-id: cf15df7f7
4 years ago
"binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_14" -> "binaryConditional#binary_conditional#15641211300815748363.a0f7e256e24b7117cb94c66e5aa27a30_13" ;
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_1" [label="1: Start binary_conditional::conditional\nFormals: \nLocals: x:binary_conditional::X 0$?%__sil_tmpSIL_materialize_temp__n$6:binary_conditional::X 0$?%__sil_tmpSIL_materialize_temp__n$7:binary_conditional::X 0$?%__sil_tmpSIL_materialize_temp__n$5:binary_conditional::X 0$?%__sil_tmp_temp_marker_n$8:_Bool a:binary_conditional::X \n " color=yellow style=filled]
[clang] fix bad interaction between ConditionalOperator and initializers Summary: This is several inter-connected changes together to keep the tests happy. The ConditionalOperator `b?t:e` is translated by first creating a placeholder variable to temporarily store the result of the evaluation in each branch, then the real thing we want to assign to reads that variable. But, there are situations where that changes the semantics of the expression, namely when the value created is a struct on the stack (eg, a C++ temporary). This is because in SIL we cannot assign the *address* of a program variable, only its contents, so by the time we're out of the conditional operator we cannot set the struct value correctly anymore: we can only set its content, which we did, but that results in a "shifted" struct value that is one dereference away from where it should be. So a batch of changes concern `conditionalOperator_trans`: - instead of systematically creating a temporary for the conditional, use the `trans_state.var_exp_typ` provided from above if available when translating `ConditionalOperator` - don't even set anything if that variable was already initialized by merely translating the branch expression, eg when it's a constructor - fix long-standing TODO to propagate these initialization facts accurately for ConditionalOperator (used by `init_expr_trans` to also figure out if it should insert a store to the variable being initialised or not) The rest of the changes adapt some relevant other constructs to deal with conditionalOperator properly now that it can set the current variable itself, instead of storing stuff inside a temp variable. This change was a problem because some constructs, eg a variable declaration, will insert nodes that set up the variable before calling its initialization, and now the initialization happens *before* that setup, in the translation of the inner conditional operator, which naturally creates nodes above the current one. - add a generic helper to force a sequential order between two translation results, forcing node creation if necessary - use that in `init_expr_trans` and `cxxNewExpr_trans` - adjust many places where `var_exp_typ` was incorrectly not reset when translating sub-expressions The sequentiality business creates more nodes when used, and the conditionalOperator business uses fewer temporary variables, so the frontend results change quite a bit. Note that biabduction tests were invaluable in debugging this. There could be other constructs to adjust similarly to cxxNewExpr that were not covered by the tests though. Added tests in pulse that exercises the previous bug. Reviewed By: da319 Differential Revision: D24796282 fbshipit-source-id: 0790c8d17
4 years ago
[clang] deal with conditionally-destroyed temporaries Summary: This was left as a TODO before: where to place calls to destructors for C++ temporaries that are only conditionally creating when evaluating an expression. This can happen inside the branches of a conditional operation `b?e:f` or in potentially-short-circuited conditions on the righ-hand side of `&&` and `||` operators. Following the compilation scheme of clang (observed by looking at the generated LLVM bitcode), we instrument the program with "marker" variables, so that for instance `X x = true?X():y;` becomes (following the execution on the true branch): ``` marker1 = 0; // initialize all markers to 0 PRUNE(true) // entering true branch X::X(&temporary); // create temporary... marker1 = 1; // ...triggers setting its marker to 1 X::X(&x, &temporary); // finish expression if (marker1) { X::~X(&temporary); // conditionally destroy the temporary } ``` In this diff, you'll find code for: - associating markers to temporaries that need them - code to initialize markers to 0 before full-expressions - code to conditionally destroy temporaries based on the values of the markers once the full-expression has finished evaluating Reviewed By: da319 Differential Revision: D24954070 fbshipit-source-id: cf15df7f7
4 years ago
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_1" -> "conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_21" ;
[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
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_2" [label="2: Exit binary_conditional::conditional \n " color=yellow style=filled]
[tests] Clean up test files shared between frontend and endtoend tests Reviewed By: jberdine Differential Revision: D3893900 fbshipit-source-id: 497effc
8 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
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_3" [label="3: Destruction(Scope) \n _=*&x:binary_conditional::X [line 28, column 1]\n n$1=_fun_binary_conditional::X::~X(&x:binary_conditional::X*) injected [line 28, column 1]\n _=*&a:binary_conditional::X [line 28, column 1]\n n$3=_fun_binary_conditional::X::~X(&a:binary_conditional::X*) injected [line 28, column 1]\n " shape="box"]
[tests] Clean up test files shared between frontend and endtoend tests Reviewed By: jberdine Differential Revision: D3893900 fbshipit-source-id: 497effc
8 years ago
[destructors] Inject destructor calls even if the destructor declaration is empty Summary: We do not inject a destructor call if the destructor declaration does not contain a body in AST. We miss all the cases where the destructor is declared in `.h` file and defined in `.cpp` file as other files include `.h` file and do not contain the body of the destructor when destructor calls are being injected based on AST information. After this diff we inject destructor calls even if we do not have body for the destructor in AST. Reviewed By: sblackshear Differential Revision: D6796567 fbshipit-source-id: 1c187ec
7 years ago
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_3" -> "conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_2" ;
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_4" [label="4: + \n " ]
[tests] Clean up test files shared between frontend and endtoend tests Reviewed By: jberdine Differential Revision: D3893900 fbshipit-source-id: 497effc
8 years ago
[clang] fix bad interaction between ConditionalOperator and initializers Summary: This is several inter-connected changes together to keep the tests happy. The ConditionalOperator `b?t:e` is translated by first creating a placeholder variable to temporarily store the result of the evaluation in each branch, then the real thing we want to assign to reads that variable. But, there are situations where that changes the semantics of the expression, namely when the value created is a struct on the stack (eg, a C++ temporary). This is because in SIL we cannot assign the *address* of a program variable, only its contents, so by the time we're out of the conditional operator we cannot set the struct value correctly anymore: we can only set its content, which we did, but that results in a "shifted" struct value that is one dereference away from where it should be. So a batch of changes concern `conditionalOperator_trans`: - instead of systematically creating a temporary for the conditional, use the `trans_state.var_exp_typ` provided from above if available when translating `ConditionalOperator` - don't even set anything if that variable was already initialized by merely translating the branch expression, eg when it's a constructor - fix long-standing TODO to propagate these initialization facts accurately for ConditionalOperator (used by `init_expr_trans` to also figure out if it should insert a store to the variable being initialised or not) The rest of the changes adapt some relevant other constructs to deal with conditionalOperator properly now that it can set the current variable itself, instead of storing stuff inside a temp variable. This change was a problem because some constructs, eg a variable declaration, will insert nodes that set up the variable before calling its initialization, and now the initialization happens *before* that setup, in the translation of the inner conditional operator, which naturally creates nodes above the current one. - add a generic helper to force a sequential order between two translation results, forcing node creation if necessary - use that in `init_expr_trans` and `cxxNewExpr_trans` - adjust many places where `var_exp_typ` was incorrectly not reset when translating sub-expressions The sequentiality business creates more nodes when used, and the conditionalOperator business uses fewer temporary variables, so the frontend results change quite a bit. Note that biabduction tests were invaluable in debugging this. There could be other constructs to adjust similarly to cxxNewExpr that were not covered by the tests though. Added tests in pulse that exercises the previous bug. Reviewed By: da319 Differential Revision: D24796282 fbshipit-source-id: 0790c8d17
4 years ago
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_4" -> "conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_14" ;
[clang] deal with conditionally-destroyed temporaries Summary: This was left as a TODO before: where to place calls to destructors for C++ temporaries that are only conditionally creating when evaluating an expression. This can happen inside the branches of a conditional operation `b?e:f` or in potentially-short-circuited conditions on the righ-hand side of `&&` and `||` operators. Following the compilation scheme of clang (observed by looking at the generated LLVM bitcode), we instrument the program with "marker" variables, so that for instance `X x = true?X():y;` becomes (following the execution on the true branch): ``` marker1 = 0; // initialize all markers to 0 PRUNE(true) // entering true branch X::X(&temporary); // create temporary... marker1 = 1; // ...triggers setting its marker to 1 X::X(&x, &temporary); // finish expression if (marker1) { X::~X(&temporary); // conditionally destroy the temporary } ``` In this diff, you'll find code for: - associating markers to temporaries that need them - code to initialize markers to 0 before full-expressions - code to conditionally destroy temporaries based on the values of the markers once the full-expression has finished evaluating Reviewed By: da319 Differential Revision: D24954070 fbshipit-source-id: cf15df7f7
4 years ago
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_5" [label="5: DeclStmt \n VARIABLE_DECLARED(0$?%__sil_tmpSIL_materialize_temp__n$6:binary_conditional::X); [line 27, column 9]\n n$10=_fun_binary_conditional::getX(&0$?%__sil_tmpSIL_materialize_temp__n$6:binary_conditional::X*) assign_last [line 27, column 9]\n " shape="box"]
[tests] Clean up test files shared between frontend and endtoend tests Reviewed By: jberdine Differential Revision: D3893900 fbshipit-source-id: 497effc
8 years ago
[destructors] Inject destructor calls even if the destructor declaration is empty Summary: We do not inject a destructor call if the destructor declaration does not contain a body in AST. We miss all the cases where the destructor is declared in `.h` file and defined in `.cpp` file as other files include `.h` file and do not contain the body of the destructor when destructor calls are being injected based on AST information. After this diff we inject destructor calls even if we do not have body for the destructor in AST. Reviewed By: sblackshear Differential Revision: D6796567 fbshipit-source-id: 1c187ec
7 years ago
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_5" -> "conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_6" ;
[clang] deal with conditionally-destroyed temporaries Summary: This was left as a TODO before: where to place calls to destructors for C++ temporaries that are only conditionally creating when evaluating an expression. This can happen inside the branches of a conditional operation `b?e:f` or in potentially-short-circuited conditions on the righ-hand side of `&&` and `||` operators. Following the compilation scheme of clang (observed by looking at the generated LLVM bitcode), we instrument the program with "marker" variables, so that for instance `X x = true?X():y;` becomes (following the execution on the true branch): ``` marker1 = 0; // initialize all markers to 0 PRUNE(true) // entering true branch X::X(&temporary); // create temporary... marker1 = 1; // ...triggers setting its marker to 1 X::X(&x, &temporary); // finish expression if (marker1) { X::~X(&temporary); // conditionally destroy the temporary } ``` In this diff, you'll find code for: - associating markers to temporaries that need them - code to initialize markers to 0 before full-expressions - code to conditionally destroy temporaries based on the values of the markers once the full-expression has finished evaluating Reviewed By: da319 Differential Revision: D24954070 fbshipit-source-id: cf15df7f7
4 years ago
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_6" [label="6: Call _fun_binary_conditional::X::operator_bool \n _=*&0$?%__sil_tmpSIL_materialize_temp__n$6:binary_conditional::X [line 27, column 9]\n n$12=_fun_binary_conditional::X::operator_bool(&0$?%__sil_tmpSIL_materialize_temp__n$6:binary_conditional::X&) [line 27, column 9]\n " shape="box"]
[tests] Clean up test files shared between frontend and endtoend tests Reviewed By: jberdine Differential Revision: D3893900 fbshipit-source-id: 497effc
8 years ago
[clang] fix bad interaction between ConditionalOperator and initializers Summary: This is several inter-connected changes together to keep the tests happy. The ConditionalOperator `b?t:e` is translated by first creating a placeholder variable to temporarily store the result of the evaluation in each branch, then the real thing we want to assign to reads that variable. But, there are situations where that changes the semantics of the expression, namely when the value created is a struct on the stack (eg, a C++ temporary). This is because in SIL we cannot assign the *address* of a program variable, only its contents, so by the time we're out of the conditional operator we cannot set the struct value correctly anymore: we can only set its content, which we did, but that results in a "shifted" struct value that is one dereference away from where it should be. So a batch of changes concern `conditionalOperator_trans`: - instead of systematically creating a temporary for the conditional, use the `trans_state.var_exp_typ` provided from above if available when translating `ConditionalOperator` - don't even set anything if that variable was already initialized by merely translating the branch expression, eg when it's a constructor - fix long-standing TODO to propagate these initialization facts accurately for ConditionalOperator (used by `init_expr_trans` to also figure out if it should insert a store to the variable being initialised or not) The rest of the changes adapt some relevant other constructs to deal with conditionalOperator properly now that it can set the current variable itself, instead of storing stuff inside a temp variable. This change was a problem because some constructs, eg a variable declaration, will insert nodes that set up the variable before calling its initialization, and now the initialization happens *before* that setup, in the translation of the inner conditional operator, which naturally creates nodes above the current one. - add a generic helper to force a sequential order between two translation results, forcing node creation if necessary - use that in `init_expr_trans` and `cxxNewExpr_trans` - adjust many places where `var_exp_typ` was incorrectly not reset when translating sub-expressions The sequentiality business creates more nodes when used, and the conditionalOperator business uses fewer temporary variables, so the frontend results change quite a bit. Note that biabduction tests were invaluable in debugging this. There could be other constructs to adjust similarly to cxxNewExpr that were not covered by the tests though. Added tests in pulse that exercises the previous bug. Reviewed By: da319 Differential Revision: D24796282 fbshipit-source-id: 0790c8d17
4 years ago
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_6" -> "conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_7" ;
[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
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_6" -> "conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_8" ;
[clang] deal with conditionally-destroyed temporaries Summary: This was left as a TODO before: where to place calls to destructors for C++ temporaries that are only conditionally creating when evaluating an expression. This can happen inside the branches of a conditional operation `b?e:f` or in potentially-short-circuited conditions on the righ-hand side of `&&` and `||` operators. Following the compilation scheme of clang (observed by looking at the generated LLVM bitcode), we instrument the program with "marker" variables, so that for instance `X x = true?X():y;` becomes (following the execution on the true branch): ``` marker1 = 0; // initialize all markers to 0 PRUNE(true) // entering true branch X::X(&temporary); // create temporary... marker1 = 1; // ...triggers setting its marker to 1 X::X(&x, &temporary); // finish expression if (marker1) { X::~X(&temporary); // conditionally destroy the temporary } ``` In this diff, you'll find code for: - associating markers to temporaries that need them - code to initialize markers to 0 before full-expressions - code to conditionally destroy temporaries based on the values of the markers once the full-expression has finished evaluating Reviewed By: da319 Differential Revision: D24954070 fbshipit-source-id: cf15df7f7
4 years ago
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_7" [label="7: Prune (true branch, boolean exp) \n PRUNE(n$12, true); [line 27, column 9]\n " shape="invhouse"]
[destructors] Inject destructor calls even if the destructor declaration is empty Summary: We do not inject a destructor call if the destructor declaration does not contain a body in AST. We miss all the cases where the destructor is declared in `.h` file and defined in `.cpp` file as other files include `.h` file and do not contain the body of the destructor when destructor calls are being injected based on AST information. After this diff we inject destructor calls even if we do not have body for the destructor in AST. Reviewed By: sblackshear Differential Revision: D6796567 fbshipit-source-id: 1c187ec
7 years ago
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_7" -> "conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_9" ;
[clang] deal with conditionally-destroyed temporaries Summary: This was left as a TODO before: where to place calls to destructors for C++ temporaries that are only conditionally creating when evaluating an expression. This can happen inside the branches of a conditional operation `b?e:f` or in potentially-short-circuited conditions on the righ-hand side of `&&` and `||` operators. Following the compilation scheme of clang (observed by looking at the generated LLVM bitcode), we instrument the program with "marker" variables, so that for instance `X x = true?X():y;` becomes (following the execution on the true branch): ``` marker1 = 0; // initialize all markers to 0 PRUNE(true) // entering true branch X::X(&temporary); // create temporary... marker1 = 1; // ...triggers setting its marker to 1 X::X(&x, &temporary); // finish expression if (marker1) { X::~X(&temporary); // conditionally destroy the temporary } ``` In this diff, you'll find code for: - associating markers to temporaries that need them - code to initialize markers to 0 before full-expressions - code to conditionally destroy temporaries based on the values of the markers once the full-expression has finished evaluating Reviewed By: da319 Differential Revision: D24954070 fbshipit-source-id: cf15df7f7
4 years ago
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_8" [label="8: Prune (false branch, boolean exp) \n PRUNE(!n$12, false); [line 27, column 9]\n " shape="invhouse"]
[clang] fix bad interaction between ConditionalOperator and initializers Summary: This is several inter-connected changes together to keep the tests happy. The ConditionalOperator `b?t:e` is translated by first creating a placeholder variable to temporarily store the result of the evaluation in each branch, then the real thing we want to assign to reads that variable. But, there are situations where that changes the semantics of the expression, namely when the value created is a struct on the stack (eg, a C++ temporary). This is because in SIL we cannot assign the *address* of a program variable, only its contents, so by the time we're out of the conditional operator we cannot set the struct value correctly anymore: we can only set its content, which we did, but that results in a "shifted" struct value that is one dereference away from where it should be. So a batch of changes concern `conditionalOperator_trans`: - instead of systematically creating a temporary for the conditional, use the `trans_state.var_exp_typ` provided from above if available when translating `ConditionalOperator` - don't even set anything if that variable was already initialized by merely translating the branch expression, eg when it's a constructor - fix long-standing TODO to propagate these initialization facts accurately for ConditionalOperator (used by `init_expr_trans` to also figure out if it should insert a store to the variable being initialised or not) The rest of the changes adapt some relevant other constructs to deal with conditionalOperator properly now that it can set the current variable itself, instead of storing stuff inside a temp variable. This change was a problem because some constructs, eg a variable declaration, will insert nodes that set up the variable before calling its initialization, and now the initialization happens *before* that setup, in the translation of the inner conditional operator, which naturally creates nodes above the current one. - add a generic helper to force a sequential order between two translation results, forcing node creation if necessary - use that in `init_expr_trans` and `cxxNewExpr_trans` - adjust many places where `var_exp_typ` was incorrectly not reset when translating sub-expressions The sequentiality business creates more nodes when used, and the conditionalOperator business uses fewer temporary variables, so the frontend results change quite a bit. Note that biabduction tests were invaluable in debugging this. There could be other constructs to adjust similarly to cxxNewExpr that were not covered by the tests though. Added tests in pulse that exercises the previous bug. Reviewed By: da319 Differential Revision: D24796282 fbshipit-source-id: 0790c8d17
4 years ago
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_8" -> "conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_11" ;
[clang] deal with conditionally-destroyed temporaries Summary: This was left as a TODO before: where to place calls to destructors for C++ temporaries that are only conditionally creating when evaluating an expression. This can happen inside the branches of a conditional operation `b?e:f` or in potentially-short-circuited conditions on the righ-hand side of `&&` and `||` operators. Following the compilation scheme of clang (observed by looking at the generated LLVM bitcode), we instrument the program with "marker" variables, so that for instance `X x = true?X():y;` becomes (following the execution on the true branch): ``` marker1 = 0; // initialize all markers to 0 PRUNE(true) // entering true branch X::X(&temporary); // create temporary... marker1 = 1; // ...triggers setting its marker to 1 X::X(&x, &temporary); // finish expression if (marker1) { X::~X(&temporary); // conditionally destroy the temporary } ``` In this diff, you'll find code for: - associating markers to temporaries that need them - code to initialize markers to 0 before full-expressions - code to conditionally destroy temporaries based on the values of the markers once the full-expression has finished evaluating Reviewed By: da319 Differential Revision: D24954070 fbshipit-source-id: cf15df7f7
4 years ago
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_9" [label="9: DeclStmt \n VARIABLE_DECLARED(0$?%__sil_tmpSIL_materialize_temp__n$7:binary_conditional::X); [line 27, column 18]\n n$14=_fun_binary_conditional::getX(&0$?%__sil_tmpSIL_materialize_temp__n$7:binary_conditional::X*) assign_last [line 27, column 18]\n *&0$?%__sil_tmp_temp_marker_n$8:_Bool=1 [line 27, column 18]\n " shape="box"]
[clang] fix bad interaction between ConditionalOperator and initializers Summary: This is several inter-connected changes together to keep the tests happy. The ConditionalOperator `b?t:e` is translated by first creating a placeholder variable to temporarily store the result of the evaluation in each branch, then the real thing we want to assign to reads that variable. But, there are situations where that changes the semantics of the expression, namely when the value created is a struct on the stack (eg, a C++ temporary). This is because in SIL we cannot assign the *address* of a program variable, only its contents, so by the time we're out of the conditional operator we cannot set the struct value correctly anymore: we can only set its content, which we did, but that results in a "shifted" struct value that is one dereference away from where it should be. So a batch of changes concern `conditionalOperator_trans`: - instead of systematically creating a temporary for the conditional, use the `trans_state.var_exp_typ` provided from above if available when translating `ConditionalOperator` - don't even set anything if that variable was already initialized by merely translating the branch expression, eg when it's a constructor - fix long-standing TODO to propagate these initialization facts accurately for ConditionalOperator (used by `init_expr_trans` to also figure out if it should insert a store to the variable being initialised or not) The rest of the changes adapt some relevant other constructs to deal with conditionalOperator properly now that it can set the current variable itself, instead of storing stuff inside a temp variable. This change was a problem because some constructs, eg a variable declaration, will insert nodes that set up the variable before calling its initialization, and now the initialization happens *before* that setup, in the translation of the inner conditional operator, which naturally creates nodes above the current one. - add a generic helper to force a sequential order between two translation results, forcing node creation if necessary - use that in `init_expr_trans` and `cxxNewExpr_trans` - adjust many places where `var_exp_typ` was incorrectly not reset when translating sub-expressions The sequentiality business creates more nodes when used, and the conditionalOperator business uses fewer temporary variables, so the frontend results change quite a bit. Note that biabduction tests were invaluable in debugging this. There could be other constructs to adjust similarly to cxxNewExpr that were not covered by the tests though. Added tests in pulse that exercises the previous bug. Reviewed By: da319 Differential Revision: D24796282 fbshipit-source-id: 0790c8d17
4 years ago
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_9" -> "conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_10" ;
[clang] deal with conditionally-destroyed temporaries Summary: This was left as a TODO before: where to place calls to destructors for C++ temporaries that are only conditionally creating when evaluating an expression. This can happen inside the branches of a conditional operation `b?e:f` or in potentially-short-circuited conditions on the righ-hand side of `&&` and `||` operators. Following the compilation scheme of clang (observed by looking at the generated LLVM bitcode), we instrument the program with "marker" variables, so that for instance `X x = true?X():y;` becomes (following the execution on the true branch): ``` marker1 = 0; // initialize all markers to 0 PRUNE(true) // entering true branch X::X(&temporary); // create temporary... marker1 = 1; // ...triggers setting its marker to 1 X::X(&x, &temporary); // finish expression if (marker1) { X::~X(&temporary); // conditionally destroy the temporary } ``` In this diff, you'll find code for: - associating markers to temporaries that need them - code to initialize markers to 0 before full-expressions - code to conditionally destroy temporaries based on the values of the markers once the full-expression has finished evaluating Reviewed By: da319 Differential Revision: D24954070 fbshipit-source-id: cf15df7f7
4 years ago
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_10" [label="10: ConditionalStmt Branch \n n$15=_fun_binary_conditional::X::X(&0$?%__sil_tmpSIL_materialize_temp__n$5:binary_conditional::X*,&0$?%__sil_tmpSIL_materialize_temp__n$7:binary_conditional::X&) [line 27, column 18]\n " shape="box"]
[clang] fix bad interaction between ConditionalOperator and initializers Summary: This is several inter-connected changes together to keep the tests happy. The ConditionalOperator `b?t:e` is translated by first creating a placeholder variable to temporarily store the result of the evaluation in each branch, then the real thing we want to assign to reads that variable. But, there are situations where that changes the semantics of the expression, namely when the value created is a struct on the stack (eg, a C++ temporary). This is because in SIL we cannot assign the *address* of a program variable, only its contents, so by the time we're out of the conditional operator we cannot set the struct value correctly anymore: we can only set its content, which we did, but that results in a "shifted" struct value that is one dereference away from where it should be. So a batch of changes concern `conditionalOperator_trans`: - instead of systematically creating a temporary for the conditional, use the `trans_state.var_exp_typ` provided from above if available when translating `ConditionalOperator` - don't even set anything if that variable was already initialized by merely translating the branch expression, eg when it's a constructor - fix long-standing TODO to propagate these initialization facts accurately for ConditionalOperator (used by `init_expr_trans` to also figure out if it should insert a store to the variable being initialised or not) The rest of the changes adapt some relevant other constructs to deal with conditionalOperator properly now that it can set the current variable itself, instead of storing stuff inside a temp variable. This change was a problem because some constructs, eg a variable declaration, will insert nodes that set up the variable before calling its initialization, and now the initialization happens *before* that setup, in the translation of the inner conditional operator, which naturally creates nodes above the current one. - add a generic helper to force a sequential order between two translation results, forcing node creation if necessary - use that in `init_expr_trans` and `cxxNewExpr_trans` - adjust many places where `var_exp_typ` was incorrectly not reset when translating sub-expressions The sequentiality business creates more nodes when used, and the conditionalOperator business uses fewer temporary variables, so the frontend results change quite a bit. Note that biabduction tests were invaluable in debugging this. There could be other constructs to adjust similarly to cxxNewExpr that were not covered by the tests though. Added tests in pulse that exercises the previous bug. Reviewed By: da319 Differential Revision: D24796282 fbshipit-source-id: 0790c8d17
4 years ago
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_10" -> "conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_4" ;
[clang] deal with conditionally-destroyed temporaries Summary: This was left as a TODO before: where to place calls to destructors for C++ temporaries that are only conditionally creating when evaluating an expression. This can happen inside the branches of a conditional operation `b?e:f` or in potentially-short-circuited conditions on the righ-hand side of `&&` and `||` operators. Following the compilation scheme of clang (observed by looking at the generated LLVM bitcode), we instrument the program with "marker" variables, so that for instance `X x = true?X():y;` becomes (following the execution on the true branch): ``` marker1 = 0; // initialize all markers to 0 PRUNE(true) // entering true branch X::X(&temporary); // create temporary... marker1 = 1; // ...triggers setting its marker to 1 X::X(&x, &temporary); // finish expression if (marker1) { X::~X(&temporary); // conditionally destroy the temporary } ``` In this diff, you'll find code for: - associating markers to temporaries that need them - code to initialize markers to 0 before full-expressions - code to conditionally destroy temporaries based on the values of the markers once the full-expression has finished evaluating Reviewed By: da319 Differential Revision: D24954070 fbshipit-source-id: cf15df7f7
4 years ago
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_11" [label="11: ConditionalStmt Branch \n n$16=_fun_binary_conditional::X::X(&0$?%__sil_tmpSIL_materialize_temp__n$5:binary_conditional::X*,&a:binary_conditional::X&) [line 27, column 27]\n " shape="box"]
[clang] fix bad interaction between ConditionalOperator and initializers Summary: This is several inter-connected changes together to keep the tests happy. The ConditionalOperator `b?t:e` is translated by first creating a placeholder variable to temporarily store the result of the evaluation in each branch, then the real thing we want to assign to reads that variable. But, there are situations where that changes the semantics of the expression, namely when the value created is a struct on the stack (eg, a C++ temporary). This is because in SIL we cannot assign the *address* of a program variable, only its contents, so by the time we're out of the conditional operator we cannot set the struct value correctly anymore: we can only set its content, which we did, but that results in a "shifted" struct value that is one dereference away from where it should be. So a batch of changes concern `conditionalOperator_trans`: - instead of systematically creating a temporary for the conditional, use the `trans_state.var_exp_typ` provided from above if available when translating `ConditionalOperator` - don't even set anything if that variable was already initialized by merely translating the branch expression, eg when it's a constructor - fix long-standing TODO to propagate these initialization facts accurately for ConditionalOperator (used by `init_expr_trans` to also figure out if it should insert a store to the variable being initialised or not) The rest of the changes adapt some relevant other constructs to deal with conditionalOperator properly now that it can set the current variable itself, instead of storing stuff inside a temp variable. This change was a problem because some constructs, eg a variable declaration, will insert nodes that set up the variable before calling its initialization, and now the initialization happens *before* that setup, in the translation of the inner conditional operator, which naturally creates nodes above the current one. - add a generic helper to force a sequential order between two translation results, forcing node creation if necessary - use that in `init_expr_trans` and `cxxNewExpr_trans` - adjust many places where `var_exp_typ` was incorrectly not reset when translating sub-expressions The sequentiality business creates more nodes when used, and the conditionalOperator business uses fewer temporary variables, so the frontend results change quite a bit. Note that biabduction tests were invaluable in debugging this. There could be other constructs to adjust similarly to cxxNewExpr that were not covered by the tests though. Added tests in pulse that exercises the previous bug. Reviewed By: da319 Differential Revision: D24796282 fbshipit-source-id: 0790c8d17
4 years ago
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_11" -> "conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_4" ;
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_12" [label="12: DeclStmt \n VARIABLE_DECLARED(0$?%__sil_tmpSIL_materialize_temp__n$5:binary_conditional::X); [line 27, column 9]\n " shape="box"]
[tests] Clean up test files shared between frontend and endtoend tests Reviewed By: jberdine Differential Revision: D3893900 fbshipit-source-id: 497effc
8 years ago
[clang] fix bad interaction between ConditionalOperator and initializers Summary: This is several inter-connected changes together to keep the tests happy. The ConditionalOperator `b?t:e` is translated by first creating a placeholder variable to temporarily store the result of the evaluation in each branch, then the real thing we want to assign to reads that variable. But, there are situations where that changes the semantics of the expression, namely when the value created is a struct on the stack (eg, a C++ temporary). This is because in SIL we cannot assign the *address* of a program variable, only its contents, so by the time we're out of the conditional operator we cannot set the struct value correctly anymore: we can only set its content, which we did, but that results in a "shifted" struct value that is one dereference away from where it should be. So a batch of changes concern `conditionalOperator_trans`: - instead of systematically creating a temporary for the conditional, use the `trans_state.var_exp_typ` provided from above if available when translating `ConditionalOperator` - don't even set anything if that variable was already initialized by merely translating the branch expression, eg when it's a constructor - fix long-standing TODO to propagate these initialization facts accurately for ConditionalOperator (used by `init_expr_trans` to also figure out if it should insert a store to the variable being initialised or not) The rest of the changes adapt some relevant other constructs to deal with conditionalOperator properly now that it can set the current variable itself, instead of storing stuff inside a temp variable. This change was a problem because some constructs, eg a variable declaration, will insert nodes that set up the variable before calling its initialization, and now the initialization happens *before* that setup, in the translation of the inner conditional operator, which naturally creates nodes above the current one. - add a generic helper to force a sequential order between two translation results, forcing node creation if necessary - use that in `init_expr_trans` and `cxxNewExpr_trans` - adjust many places where `var_exp_typ` was incorrectly not reset when translating sub-expressions The sequentiality business creates more nodes when used, and the conditionalOperator business uses fewer temporary variables, so the frontend results change quite a bit. Note that biabduction tests were invaluable in debugging this. There could be other constructs to adjust similarly to cxxNewExpr that were not covered by the tests though. Added tests in pulse that exercises the previous bug. Reviewed By: da319 Differential Revision: D24796282 fbshipit-source-id: 0790c8d17
4 years ago
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_12" -> "conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_5" ;
[clang] deal with conditionally-destroyed temporaries Summary: This was left as a TODO before: where to place calls to destructors for C++ temporaries that are only conditionally creating when evaluating an expression. This can happen inside the branches of a conditional operation `b?e:f` or in potentially-short-circuited conditions on the righ-hand side of `&&` and `||` operators. Following the compilation scheme of clang (observed by looking at the generated LLVM bitcode), we instrument the program with "marker" variables, so that for instance `X x = true?X():y;` becomes (following the execution on the true branch): ``` marker1 = 0; // initialize all markers to 0 PRUNE(true) // entering true branch X::X(&temporary); // create temporary... marker1 = 1; // ...triggers setting its marker to 1 X::X(&x, &temporary); // finish expression if (marker1) { X::~X(&temporary); // conditionally destroy the temporary } ``` In this diff, you'll find code for: - associating markers to temporaries that need them - code to initialize markers to 0 before full-expressions - code to conditionally destroy temporaries based on the values of the markers once the full-expression has finished evaluating Reviewed By: da319 Differential Revision: D24954070 fbshipit-source-id: cf15df7f7
4 years ago
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_13" [label="13: ExprWithCleanups \n VARIABLE_DECLARED(0$?%__sil_tmp_temp_marker_n$8:_Bool); [line 27, column 9]\n *&0$?%__sil_tmp_temp_marker_n$8:_Bool=0 [line 27, column 9]\n " shape="box"]
[tests] Clean up test files shared between frontend and endtoend tests Reviewed By: jberdine Differential Revision: D3893900 fbshipit-source-id: 497effc
8 years ago
[clang] fix bad interaction between ConditionalOperator and initializers Summary: This is several inter-connected changes together to keep the tests happy. The ConditionalOperator `b?t:e` is translated by first creating a placeholder variable to temporarily store the result of the evaluation in each branch, then the real thing we want to assign to reads that variable. But, there are situations where that changes the semantics of the expression, namely when the value created is a struct on the stack (eg, a C++ temporary). This is because in SIL we cannot assign the *address* of a program variable, only its contents, so by the time we're out of the conditional operator we cannot set the struct value correctly anymore: we can only set its content, which we did, but that results in a "shifted" struct value that is one dereference away from where it should be. So a batch of changes concern `conditionalOperator_trans`: - instead of systematically creating a temporary for the conditional, use the `trans_state.var_exp_typ` provided from above if available when translating `ConditionalOperator` - don't even set anything if that variable was already initialized by merely translating the branch expression, eg when it's a constructor - fix long-standing TODO to propagate these initialization facts accurately for ConditionalOperator (used by `init_expr_trans` to also figure out if it should insert a store to the variable being initialised or not) The rest of the changes adapt some relevant other constructs to deal with conditionalOperator properly now that it can set the current variable itself, instead of storing stuff inside a temp variable. This change was a problem because some constructs, eg a variable declaration, will insert nodes that set up the variable before calling its initialization, and now the initialization happens *before* that setup, in the translation of the inner conditional operator, which naturally creates nodes above the current one. - add a generic helper to force a sequential order between two translation results, forcing node creation if necessary - use that in `init_expr_trans` and `cxxNewExpr_trans` - adjust many places where `var_exp_typ` was incorrectly not reset when translating sub-expressions The sequentiality business creates more nodes when used, and the conditionalOperator business uses fewer temporary variables, so the frontend results change quite a bit. Note that biabduction tests were invaluable in debugging this. There could be other constructs to adjust similarly to cxxNewExpr that were not covered by the tests though. Added tests in pulse that exercises the previous bug. Reviewed By: da319 Differential Revision: D24796282 fbshipit-source-id: 0790c8d17
4 years ago
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_13" -> "conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_12" ;
[clang] deal with conditionally-destroyed temporaries Summary: This was left as a TODO before: where to place calls to destructors for C++ temporaries that are only conditionally creating when evaluating an expression. This can happen inside the branches of a conditional operation `b?e:f` or in potentially-short-circuited conditions on the righ-hand side of `&&` and `||` operators. Following the compilation scheme of clang (observed by looking at the generated LLVM bitcode), we instrument the program with "marker" variables, so that for instance `X x = true?X():y;` becomes (following the execution on the true branch): ``` marker1 = 0; // initialize all markers to 0 PRUNE(true) // entering true branch X::X(&temporary); // create temporary... marker1 = 1; // ...triggers setting its marker to 1 X::X(&x, &temporary); // finish expression if (marker1) { X::~X(&temporary); // conditionally destroy the temporary } ``` In this diff, you'll find code for: - associating markers to temporaries that need them - code to initialize markers to 0 before full-expressions - code to conditionally destroy temporaries based on the values of the markers once the full-expression has finished evaluating Reviewed By: da319 Differential Revision: D24954070 fbshipit-source-id: cf15df7f7
4 years ago
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_14" [label="14: ExprWithCleanups \n n$17=_fun_binary_conditional::X::X(&x:binary_conditional::X*,&0$?%__sil_tmpSIL_materialize_temp__n$5:binary_conditional::X&) [line 27, column 9]\n " shape="box"]
[tests] Clean up test files shared between frontend and endtoend tests Reviewed By: jberdine Differential Revision: D3893900 fbshipit-source-id: 497effc
8 years ago
[clang] deal with conditionally-destroyed temporaries Summary: This was left as a TODO before: where to place calls to destructors for C++ temporaries that are only conditionally creating when evaluating an expression. This can happen inside the branches of a conditional operation `b?e:f` or in potentially-short-circuited conditions on the righ-hand side of `&&` and `||` operators. Following the compilation scheme of clang (observed by looking at the generated LLVM bitcode), we instrument the program with "marker" variables, so that for instance `X x = true?X():y;` becomes (following the execution on the true branch): ``` marker1 = 0; // initialize all markers to 0 PRUNE(true) // entering true branch X::X(&temporary); // create temporary... marker1 = 1; // ...triggers setting its marker to 1 X::X(&x, &temporary); // finish expression if (marker1) { X::~X(&temporary); // conditionally destroy the temporary } ``` In this diff, you'll find code for: - associating markers to temporaries that need them - code to initialize markers to 0 before full-expressions - code to conditionally destroy temporaries based on the values of the markers once the full-expression has finished evaluating Reviewed By: da319 Differential Revision: D24954070 fbshipit-source-id: cf15df7f7
4 years ago
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_14" -> "conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_17" ;
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_14" -> "conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_18" ;
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_15" [label="15: + \n " ]
[tests] Clean up test files shared between frontend and endtoend tests Reviewed By: jberdine Differential Revision: D3893900 fbshipit-source-id: 497effc
8 years ago
[clang] deal with conditionally-destroyed temporaries Summary: This was left as a TODO before: where to place calls to destructors for C++ temporaries that are only conditionally creating when evaluating an expression. This can happen inside the branches of a conditional operation `b?e:f` or in potentially-short-circuited conditions on the righ-hand side of `&&` and `||` operators. Following the compilation scheme of clang (observed by looking at the generated LLVM bitcode), we instrument the program with "marker" variables, so that for instance `X x = true?X():y;` becomes (following the execution on the true branch): ``` marker1 = 0; // initialize all markers to 0 PRUNE(true) // entering true branch X::X(&temporary); // create temporary... marker1 = 1; // ...triggers setting its marker to 1 X::X(&x, &temporary); // finish expression if (marker1) { X::~X(&temporary); // conditionally destroy the temporary } ``` In this diff, you'll find code for: - associating markers to temporaries that need them - code to initialize markers to 0 before full-expressions - code to conditionally destroy temporaries based on the values of the markers once the full-expression has finished evaluating Reviewed By: da319 Differential Revision: D24954070 fbshipit-source-id: cf15df7f7
4 years ago
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_15" -> "conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_19" ;
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_16" [label="16: Destruction(temporaries cleanup) \n _=*&0$?%__sil_tmpSIL_materialize_temp__n$7:binary_conditional::X [line 27, column 27]\n n$23=_fun_binary_conditional::X::~X(&0$?%__sil_tmpSIL_materialize_temp__n$7:binary_conditional::X*) injected [line 27, column 27]\n " shape="box"]
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_16" -> "conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_15" ;
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_17" [label="17: Prune (true branch, if) \n n$24=*&0$?%__sil_tmp_temp_marker_n$8:_Bool [line 27, column 27]\n PRUNE(n$24, true); [line 27, column 27]\n " shape="invhouse"]
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_17" -> "conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_16" ;
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_18" [label="18: Prune (false branch, if) \n n$24=*&0$?%__sil_tmp_temp_marker_n$8:_Bool [line 27, column 27]\n PRUNE(!n$24, false); [line 27, column 27]\n " shape="invhouse"]
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_18" -> "conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_15" ;
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_19" [label="19: Destruction(temporaries cleanup) \n _=*&0$?%__sil_tmpSIL_materialize_temp__n$6:binary_conditional::X [line 27, column 27]\n n$21=_fun_binary_conditional::X::~X(&0$?%__sil_tmpSIL_materialize_temp__n$6:binary_conditional::X*) injected [line 27, column 27]\n _=*&0$?%__sil_tmpSIL_materialize_temp__n$5:binary_conditional::X [line 27, column 27]\n n$19=_fun_binary_conditional::X::~X(&0$?%__sil_tmpSIL_materialize_temp__n$5:binary_conditional::X*) injected [line 27, column 27]\n " shape="box"]
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_19" -> "conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_3" ;
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_20" [label="20: DeclStmt \n VARIABLE_DECLARED(x:binary_conditional::X); [line 27, column 3]\n " shape="box"]
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_20" -> "conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_13" ;
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_21" [label="21: DeclStmt \n VARIABLE_DECLARED(a:binary_conditional::X); [line 26, column 3]\n n$25=_fun_binary_conditional::X::X(&a:binary_conditional::X*) [line 26, column 5]\n " shape="box"]
"conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_21" -> "conditional#binary_conditional#4777209206611953450.41decaebdce6325bd31c1d47d4647c45_20" ;
Get rid of Declare_locals Reviewed By: jeremydubreil Differential Revision: D9234331 fbshipit-source-id: 70443eabe
6 years ago
"getX#binary_conditional(class binary_conditional::X)#7708042186122353096.8825a5a3afa327848f6dcf77ec0e3f60_1" [label="1: Start binary_conditional::getX\nFormals: __return_param:binary_conditional::X*\nLocals: x:binary_conditional::X \n " color=yellow style=filled]
[tests] Clean up test files shared between frontend and endtoend tests Reviewed By: jberdine Differential Revision: D3893900 fbshipit-source-id: 497effc
8 years ago
[clang] change the way we wire up return statements Summary: Split the translation of return more aggressively between: 1. the instruction that has to happen before the translation of the sub-expr 2. the sub-expr 3. the instruction that has to happen after the sub-expr This is needed for the next diff which creates potentially large CFGs in (2). Reviewed By: da319 Differential Revision: D24954071 fbshipit-source-id: a7e7e2527
4 years ago
"getX#binary_conditional(class binary_conditional::X)#7708042186122353096.8825a5a3afa327848f6dcf77ec0e3f60_1" -> "getX#binary_conditional(class binary_conditional::X)#7708042186122353096.8825a5a3afa327848f6dcf77ec0e3f60_6" ;
[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
"getX#binary_conditional(class binary_conditional::X)#7708042186122353096.8825a5a3afa327848f6dcf77ec0e3f60_2" [label="2: Exit binary_conditional::getX \n " color=yellow style=filled]
[tests] Clean up test files shared between frontend and endtoend tests Reviewed By: jberdine Differential Revision: D3893900 fbshipit-source-id: 497effc
8 years ago
[clang] change the way we wire up return statements Summary: Split the translation of return more aggressively between: 1. the instruction that has to happen before the translation of the sub-expr 2. the sub-expr 3. the instruction that has to happen after the sub-expr This is needed for the next diff which creates potentially large CFGs in (2). Reviewed By: da319 Differential Revision: D24954071 fbshipit-source-id: a7e7e2527
4 years ago
"getX#binary_conditional(class binary_conditional::X)#7708042186122353096.8825a5a3afa327848f6dcf77ec0e3f60_3" [label="3: Return Stmt \n n$0=*&__return_param:binary_conditional::X* [line 16, column 3]\n " shape="box"]
[tests] Clean up test files shared between frontend and endtoend tests Reviewed By: jberdine Differential Revision: D3893900 fbshipit-source-id: 497effc
8 years ago
[clang] change the way we wire up return statements Summary: Split the translation of return more aggressively between: 1. the instruction that has to happen before the translation of the sub-expr 2. the sub-expr 3. the instruction that has to happen after the sub-expr This is needed for the next diff which creates potentially large CFGs in (2). Reviewed By: da319 Differential Revision: D24954071 fbshipit-source-id: a7e7e2527
4 years ago
"getX#binary_conditional(class binary_conditional::X)#7708042186122353096.8825a5a3afa327848f6dcf77ec0e3f60_3" -> "getX#binary_conditional(class binary_conditional::X)#7708042186122353096.8825a5a3afa327848f6dcf77ec0e3f60_4" ;
"getX#binary_conditional(class binary_conditional::X)#7708042186122353096.8825a5a3afa327848f6dcf77ec0e3f60_4" [label="4: Return Stmt \n n$1=_fun_binary_conditional::X::X(n$0:binary_conditional::X*,&x:binary_conditional::X&) [line 16, column 10]\n " shape="box"]
[tests] Clean up test files shared between frontend and endtoend tests Reviewed By: jberdine Differential Revision: D3893900 fbshipit-source-id: 497effc
8 years ago
[clang] change the way we wire up return statements Summary: Split the translation of return more aggressively between: 1. the instruction that has to happen before the translation of the sub-expr 2. the sub-expr 3. the instruction that has to happen after the sub-expr This is needed for the next diff which creates potentially large CFGs in (2). Reviewed By: da319 Differential Revision: D24954071 fbshipit-source-id: a7e7e2527
4 years ago
"getX#binary_conditional(class binary_conditional::X)#7708042186122353096.8825a5a3afa327848f6dcf77ec0e3f60_4" -> "getX#binary_conditional(class binary_conditional::X)#7708042186122353096.8825a5a3afa327848f6dcf77ec0e3f60_5" ;
"getX#binary_conditional(class binary_conditional::X)#7708042186122353096.8825a5a3afa327848f6dcf77ec0e3f60_5" [label="5: Return Stmt \n _=*&x:binary_conditional::X [line 16, column 10]\n n$3=_fun_binary_conditional::X::~X(&x:binary_conditional::X*) injected [line 16, column 10]\n " shape="box"]
"getX#binary_conditional(class binary_conditional::X)#7708042186122353096.8825a5a3afa327848f6dcf77ec0e3f60_5" -> "getX#binary_conditional(class binary_conditional::X)#7708042186122353096.8825a5a3afa327848f6dcf77ec0e3f60_2" ;
"getX#binary_conditional(class binary_conditional::X)#7708042186122353096.8825a5a3afa327848f6dcf77ec0e3f60_6" [label="6: DeclStmt \n VARIABLE_DECLARED(x:binary_conditional::X); [line 15, column 3]\n n$5=_fun_binary_conditional::X::X(&x:binary_conditional::X*) [line 15, column 5]\n " shape="box"]
"getX#binary_conditional(class binary_conditional::X)#7708042186122353096.8825a5a3afa327848f6dcf77ec0e3f60_6" -> "getX#binary_conditional(class binary_conditional::X)#7708042186122353096.8825a5a3afa327848f6dcf77ec0e3f60_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
"operator_bool#X#binary_conditional#(663222161121279878).1074e20ff76c2575638dad4d7c1539a7_1" [label="1: Start binary_conditional::X::operator_bool\nFormals: this:binary_conditional::X*\nLocals: \n " color=yellow style=filled]
[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
"operator_bool#X#binary_conditional#(663222161121279878).1074e20ff76c2575638dad4d7c1539a7_1" -> "operator_bool#X#binary_conditional#(663222161121279878).1074e20ff76c2575638dad4d7c1539a7_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
"operator_bool#X#binary_conditional#(663222161121279878).1074e20ff76c2575638dad4d7c1539a7_2" [label="2: Exit binary_conditional::X::operator_bool \n " color=yellow style=filled]
[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
[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
"operator_bool#X#binary_conditional#(663222161121279878).1074e20ff76c2575638dad4d7c1539a7_3" [label="3: Return Stmt \n *&return:_Bool=1 [line 11, column 21]\n " shape="box"]
[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
"operator_bool#X#binary_conditional#(663222161121279878).1074e20ff76c2575638dad4d7c1539a7_3" -> "operator_bool#X#binary_conditional#(663222161121279878).1074e20ff76c2575638dad4d7c1539a7_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
"X#X#binary_conditional#{14263889156663411855|constexpr}.2259daea109ab4ed7cb747998c1a8b38_1" [label="1: Start binary_conditional::X::X\nFormals: this:binary_conditional::X*\nLocals: \n " color=yellow style=filled]
Propagate C++ noexcept annotation from frontend to backend Reviewed By: jeremydubreil Differential Revision: D5167568 fbshipit-source-id: b562d5e
8 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
"X#X#binary_conditional#{14263889156663411855|constexpr}.2259daea109ab4ed7cb747998c1a8b38_1" -> "X#X#binary_conditional#{14263889156663411855|constexpr}.2259daea109ab4ed7cb747998c1a8b38_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
"X#X#binary_conditional#{14263889156663411855|constexpr}.2259daea109ab4ed7cb747998c1a8b38_2" [label="2: Exit binary_conditional::X::X \n " color=yellow style=filled]
Propagate C++ noexcept annotation from frontend to backend Reviewed By: jeremydubreil Differential Revision: D5167568 fbshipit-source-id: b562d5e
8 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
"X#X#binary_conditional#{984623546922473120|constexpr}.75245961304dd439037ceba4c9251935_1" [label="1: Start binary_conditional::X::X\nFormals: this:binary_conditional::X* __param_0:binary_conditional::X&\nLocals: \n " color=yellow style=filled]
[clang] Get translation unit language from AST dump Summary: New version of clang plugin exports `-x` arg information as a part of TranslationUnitDecl. Get it from there instead of reading it from clang argv Reviewed By: jvillard Differential Revision: D4112652 fbshipit-source-id: 5c3af1f
8 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
"X#X#binary_conditional#{984623546922473120|constexpr}.75245961304dd439037ceba4c9251935_1" -> "X#X#binary_conditional#{984623546922473120|constexpr}.75245961304dd439037ceba4c9251935_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
"X#X#binary_conditional#{984623546922473120|constexpr}.75245961304dd439037ceba4c9251935_2" [label="2: Exit binary_conditional::X::X \n " color=yellow style=filled]
[tests] Clean up test files shared between frontend and endtoend tests Reviewed By: jberdine Differential Revision: D3893900 fbshipit-source-id: 497effc
8 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
"X#X#binary_conditional#{9863553346576066468|constexpr}.13550d5872419d596c3c38205883714d_1" [label="1: Start binary_conditional::X::X\nFormals: this:binary_conditional::X* __param_0:binary_conditional::X const &\nLocals: \n " color=yellow style=filled]
[tests] Clean up test files shared between frontend and endtoend tests Reviewed By: jberdine Differential Revision: D3893900 fbshipit-source-id: 497effc
8 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
"X#X#binary_conditional#{9863553346576066468|constexpr}.13550d5872419d596c3c38205883714d_1" -> "X#X#binary_conditional#{9863553346576066468|constexpr}.13550d5872419d596c3c38205883714d_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
"X#X#binary_conditional#{9863553346576066468|constexpr}.13550d5872419d596c3c38205883714d_2" [label="2: Exit binary_conditional::X::X \n " color=yellow style=filled]
Sort nodes when printing cfg to dot file Summary: Currently cfg nodes are written into dot files in whatever order they appear in a hash table. This seems unnecessarily sensitive, so this diff sorts the nodes. Reviewed By: dulmarod Differential Revision: D4232377 fbshipit-source-id: a907cc6
8 years ago
[tests] Clean up test files shared between frontend and endtoend tests Reviewed By: jberdine Differential Revision: D3893900 fbshipit-source-id: 497effc
8 years ago
}