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 '2d8f404a5f'
${ noResults }
infer_clone/infer/tests/codetoanalyze/cpp/shared/exceptions/Exceptions.cpp.dot

257 lines
26 KiB
Raw Normal View History Unescape

Add @generated comment to icfg.dot files Reviewed By: jvillard Differential Revision: D3358243 fbshipit-source-id: a47cc01
9 years ago
/* @generated */
[cfg] rename iCFG to cfg in dotty files Summary: Not sure what an "iCFG" is but the dotty is only about CFGs anyway. Diff obtained by mass-`sed`. Reviewed By: sblackshear Differential Revision: D6324280 fbshipit-source-id: b7603bb
7 years ago
digraph cfg {
[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
"FN_deref_null_after_catch_bad#4627123003703707696.43441e3badf1bb571cbe770f9d51a51c_1" [label="1: Start FN_deref_null_after_catch_bad\nFormals: i:int*\nLocals: 0$?%__sil_tmp__temp_construct_n$3:std::runtime_error 0$?%__sil_tmpSIL_materialize_temp__n$2:std::runtime_error const \n " color=yellow style=filled]
[clang] basic support for exceptional control-flow Summary: This diff: - translates C++ `catch` blocks - adds an exceptional control-flow edge from the end of a `try` block to the beginning of a `catch` block This obviously doesn't reflect the way exceptions actually work, but I think it is better than what we have now. For one thing, we'll see/translate code inside `catch` blocks, which were opaque before. If Clang analyses don't want this behavior, they can simply use `ProcCfg.Normal` (which, up until this diff, behaved identically to `ProcCfg.Exceptional`. In the future, we can extend `trans_state` to track blocks that might throw an exception, and have each of these blocks transition to `catch` instead. Reviewed By: jvillard Differential Revision: D7814521 fbshipit-source-id: 67b86a6
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
"FN_deref_null_after_catch_bad#4627123003703707696.43441e3badf1bb571cbe770f9d51a51c_1" -> "FN_deref_null_after_catch_bad#4627123003703707696.43441e3badf1bb571cbe770f9d51a51c_7" ;
[cfg] run pre-analysis lazily in ondemand Summary: This also prints the CFGs *after* pre-analysis for individual procedures in infer-out/captured/<filename>/<proc>.dot. One can also look up the CFGs before pre-analysis in infer-out/captured/proc_cfgs_frontend.dot. Context: I want to add a pre-analysis that needs to look at proc attributes inter-procedurally. For this to make sense it has to happen *after* all of capture, and before analysis. Thus, this diff brings back the lazy running of the pre-analysis like in D15803492, except that we still make sure to run the pre-analyses systematically regardless of the checkers being run by running the pre-analysis from ondemand.ml. Also we don't need to re-introduce the "did_preanalysis" proc attribute for the same reason that the pre-analysis is now run once and for all by ondemand.ml (instead of each individual checker back in the days). This has the benefit of running the pre-analysis only when needed, and the drawback that several concurrent processes analysing the same proc descs will duplicate work. Since pre-analyses are supposed to be very fast I assume that neither is a big deal. If they become more expensive then the benefit gets bigger and the drawback is just the same as with regular analyses. Reviewed By: skcho Differential Revision: D18573920 fbshipit-source-id: de350eaef
5 years ago
"FN_deref_null_after_catch_bad#4627123003703707696.43441e3badf1bb571cbe770f9d51a51c_2" [label="2: Exit FN_deref_null_after_catch_bad \n " color=yellow style=filled]
[clang] basic support for exceptional control-flow Summary: This diff: - translates C++ `catch` blocks - adds an exceptional control-flow edge from the end of a `try` block to the beginning of a `catch` block This obviously doesn't reflect the way exceptions actually work, but I think it is better than what we have now. For one thing, we'll see/translate code inside `catch` blocks, which were opaque before. If Clang analyses don't want this behavior, they can simply use `ProcCfg.Normal` (which, up until this diff, behaved identically to `ProcCfg.Exceptional`. In the future, we can extend `trans_state` to track blocks that might throw an exception, and have each of these blocks transition to `catch` instead. Reviewed By: jvillard Differential Revision: D7814521 fbshipit-source-id: 67b86a6
7 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
"FN_deref_null_after_catch_bad#4627123003703707696.43441e3badf1bb571cbe770f9d51a51c_3" [label="3: Return Stmt \n n$0=*&i:int* [line 52, column 11]\n n$1=*n$0:int [line 52, column 10]\n " shape="box"]
[clang] basic support for exceptional control-flow Summary: This diff: - translates C++ `catch` blocks - adds an exceptional control-flow edge from the end of a `try` block to the beginning of a `catch` block This obviously doesn't reflect the way exceptions actually work, but I think it is better than what we have now. For one thing, we'll see/translate code inside `catch` blocks, which were opaque before. If Clang analyses don't want this behavior, they can simply use `ProcCfg.Normal` (which, up until this diff, behaved identically to `ProcCfg.Exceptional`. In the future, we can extend `trans_state` to track blocks that might throw an exception, and have each of these blocks transition to `catch` instead. Reviewed By: jvillard Differential Revision: D7814521 fbshipit-source-id: 67b86a6
7 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
"FN_deref_null_after_catch_bad#4627123003703707696.43441e3badf1bb571cbe770f9d51a51c_3" -> "FN_deref_null_after_catch_bad#4627123003703707696.43441e3badf1bb571cbe770f9d51a51c_4" ;
"FN_deref_null_after_catch_bad#4627123003703707696.43441e3badf1bb571cbe770f9d51a51c_4" [label="4: Return Stmt \n *&return:int=n$1 [line 52, column 3]\n " shape="box"]
[clang] basic support for exceptional control-flow Summary: This diff: - translates C++ `catch` blocks - adds an exceptional control-flow edge from the end of a `try` block to the beginning of a `catch` block This obviously doesn't reflect the way exceptions actually work, but I think it is better than what we have now. For one thing, we'll see/translate code inside `catch` blocks, which were opaque before. If Clang analyses don't want this behavior, they can simply use `ProcCfg.Normal` (which, up until this diff, behaved identically to `ProcCfg.Exceptional`. In the future, we can extend `trans_state` to track blocks that might throw an exception, and have each of these blocks transition to `catch` instead. Reviewed By: jvillard Differential Revision: D7814521 fbshipit-source-id: 67b86a6
7 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
"FN_deref_null_after_catch_bad#4627123003703707696.43441e3badf1bb571cbe770f9d51a51c_4" -> "FN_deref_null_after_catch_bad#4627123003703707696.43441e3badf1bb571cbe770f9d51a51c_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
"FN_deref_null_after_catch_bad#4627123003703707696.43441e3badf1bb571cbe770f9d51a51c_5" [label="5: DeclStmt \n VARIABLE_DECLARED(0$?%__sil_tmpSIL_materialize_temp__n$2:std::runtime_error const ); [line 48, column 11]\n n$4=_fun_std::runtime_error::runtime_error(&0$?%__sil_tmpSIL_materialize_temp__n$2:std::runtime_error const *,\"error\":char const *) [line 48, column 11]\n " shape="box"]
[clang] basic support for exceptional control-flow Summary: This diff: - translates C++ `catch` blocks - adds an exceptional control-flow edge from the end of a `try` block to the beginning of a `catch` block This obviously doesn't reflect the way exceptions actually work, but I think it is better than what we have now. For one thing, we'll see/translate code inside `catch` blocks, which were opaque before. If Clang analyses don't want this behavior, they can simply use `ProcCfg.Normal` (which, up until this diff, behaved identically to `ProcCfg.Exceptional`. In the future, we can extend `trans_state` to track blocks that might throw an exception, and have each of these blocks transition to `catch` instead. Reviewed By: jvillard Differential Revision: D7814521 fbshipit-source-id: 67b86a6
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
"FN_deref_null_after_catch_bad#4627123003703707696.43441e3badf1bb571cbe770f9d51a51c_5" -> "FN_deref_null_after_catch_bad#4627123003703707696.43441e3badf1bb571cbe770f9d51a51c_6" ;
"FN_deref_null_after_catch_bad#4627123003703707696.43441e3badf1bb571cbe770f9d51a51c_6" [label="6: Destruction(temporaries cleanup) \n n$5=_fun_std::runtime_error::runtime_error(&0$?%__sil_tmp__temp_construct_n$3:std::runtime_error*,&0$?%__sil_tmpSIL_materialize_temp__n$2:std::runtime_error const &) [line 48, column 11]\n n$6=_fun___infer_objc_cpp_throw(&0$?%__sil_tmp__temp_construct_n$3:std::runtime_error) [line 48, column 5]\n _=*&0$?%__sil_tmpSIL_materialize_temp__n$2:std::runtime_error const [line 48, column 37]\n n$8=_fun_std::runtime_error::~runtime_error(&0$?%__sil_tmpSIL_materialize_temp__n$2:std::runtime_error const *) injected virtual [line 48, column 37]\n " shape="box"]
[clang] basic support for exceptional control-flow Summary: This diff: - translates C++ `catch` blocks - adds an exceptional control-flow edge from the end of a `try` block to the beginning of a `catch` block This obviously doesn't reflect the way exceptions actually work, but I think it is better than what we have now. For one thing, we'll see/translate code inside `catch` blocks, which were opaque before. If Clang analyses don't want this behavior, they can simply use `ProcCfg.Normal` (which, up until this diff, behaved identically to `ProcCfg.Exceptional`. In the future, we can extend `trans_state` to track blocks that might throw an exception, and have each of these blocks transition to `catch` instead. Reviewed By: jvillard Differential Revision: D7814521 fbshipit-source-id: 67b86a6
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
"FN_deref_null_after_catch_bad#4627123003703707696.43441e3badf1bb571cbe770f9d51a51c_6" -> "FN_deref_null_after_catch_bad#4627123003703707696.43441e3badf1bb571cbe770f9d51a51c_3" ;
"FN_deref_null_after_catch_bad#4627123003703707696.43441e3badf1bb571cbe770f9d51a51c_6" -> "FN_deref_null_after_catch_bad#4627123003703707696.43441e3badf1bb571cbe770f9d51a51c_8" [color="red" ];
"FN_deref_null_after_catch_bad#4627123003703707696.43441e3badf1bb571cbe770f9d51a51c_7" [label="7: BinaryOperatorStmt: Assign \n n$9=*&i:int* [line 47, column 6]\n *n$9:int=2 [line 47, column 5]\n " shape="box"]
[clang] basic support for exceptional control-flow Summary: This diff: - translates C++ `catch` blocks - adds an exceptional control-flow edge from the end of a `try` block to the beginning of a `catch` block This obviously doesn't reflect the way exceptions actually work, but I think it is better than what we have now. For one thing, we'll see/translate code inside `catch` blocks, which were opaque before. If Clang analyses don't want this behavior, they can simply use `ProcCfg.Normal` (which, up until this diff, behaved identically to `ProcCfg.Exceptional`. In the future, we can extend `trans_state` to track blocks that might throw an exception, and have each of these blocks transition to `catch` instead. Reviewed By: jvillard Differential Revision: D7814521 fbshipit-source-id: 67b86a6
7 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
"FN_deref_null_after_catch_bad#4627123003703707696.43441e3badf1bb571cbe770f9d51a51c_7" -> "FN_deref_null_after_catch_bad#4627123003703707696.43441e3badf1bb571cbe770f9d51a51c_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
"FN_deref_null_after_catch_bad#4627123003703707696.43441e3badf1bb571cbe770f9d51a51c_8" [label="8: BinaryOperatorStmt: Assign \n *&i:int*=null [line 50, 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
"FN_deref_null_after_catch_bad#4627123003703707696.43441e3badf1bb571cbe770f9d51a51c_8" -> "FN_deref_null_after_catch_bad#4627123003703707696.43441e3badf1bb571cbe770f9d51a51c_3" ;
"FN_deref_null_in_catch_bad#9297890526029657977.c83eec7c9ab8ce2e38ddbc08f8c3dfeb_1" [label="1: Start FN_deref_null_in_catch_bad\nFormals: \nLocals: 0$?%__sil_tmp__temp_construct_n$1:std::runtime_error 0$?%__sil_tmpSIL_materialize_temp__n$0:std::runtime_error const i:int* \n " color=yellow style=filled]
[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
[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
"FN_deref_null_in_catch_bad#9297890526029657977.c83eec7c9ab8ce2e38ddbc08f8c3dfeb_1" -> "FN_deref_null_in_catch_bad#9297890526029657977.c83eec7c9ab8ce2e38ddbc08f8c3dfeb_8" ;
[cfg] run pre-analysis lazily in ondemand Summary: This also prints the CFGs *after* pre-analysis for individual procedures in infer-out/captured/<filename>/<proc>.dot. One can also look up the CFGs before pre-analysis in infer-out/captured/proc_cfgs_frontend.dot. Context: I want to add a pre-analysis that needs to look at proc attributes inter-procedurally. For this to make sense it has to happen *after* all of capture, and before analysis. Thus, this diff brings back the lazy running of the pre-analysis like in D15803492, except that we still make sure to run the pre-analyses systematically regardless of the checkers being run by running the pre-analysis from ondemand.ml. Also we don't need to re-introduce the "did_preanalysis" proc attribute for the same reason that the pre-analysis is now run once and for all by ondemand.ml (instead of each individual checker back in the days). This has the benefit of running the pre-analysis only when needed, and the drawback that several concurrent processes analysing the same proc descs will duplicate work. Since pre-analyses are supposed to be very fast I assume that neither is a big deal. If they become more expensive then the benefit gets bigger and the drawback is just the same as with regular analyses. Reviewed By: skcho Differential Revision: D18573920 fbshipit-source-id: de350eaef
5 years ago
"FN_deref_null_in_catch_bad#9297890526029657977.c83eec7c9ab8ce2e38ddbc08f8c3dfeb_2" [label="2: Exit FN_deref_null_in_catch_bad \n " color=yellow style=filled]
[clang] destroy C++ temporaries Summary: Inject destructor calls to destroy a temporary when its lifetime ends. Reviewed By: mbouaziz Differential Revision: D15674209 fbshipit-source-id: 0f783a906
6 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
"FN_deref_null_in_catch_bad#9297890526029657977.c83eec7c9ab8ce2e38ddbc08f8c3dfeb_3" [label="3: Return Stmt \n *&return:int=0 [line 42, column 3]\n " shape="box"]
[clang] basic support for exceptional control-flow Summary: This diff: - translates C++ `catch` blocks - adds an exceptional control-flow edge from the end of a `try` block to the beginning of a `catch` block This obviously doesn't reflect the way exceptions actually work, but I think it is better than what we have now. For one thing, we'll see/translate code inside `catch` blocks, which were opaque before. If Clang analyses don't want this behavior, they can simply use `ProcCfg.Normal` (which, up until this diff, behaved identically to `ProcCfg.Exceptional`. In the future, we can extend `trans_state` to track blocks that might throw an exception, and have each of these blocks transition to `catch` instead. Reviewed By: jvillard Differential Revision: D7814521 fbshipit-source-id: 67b86a6
7 years ago
"FN_deref_null_in_catch_bad#9297890526029657977.c83eec7c9ab8ce2e38ddbc08f8c3dfeb_3" -> "FN_deref_null_in_catch_bad#9297890526029657977.c83eec7c9ab8ce2e38ddbc08f8c3dfeb_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
"FN_deref_null_in_catch_bad#9297890526029657977.c83eec7c9ab8ce2e38ddbc08f8c3dfeb_4" [label="4: DeclStmt \n VARIABLE_DECLARED(0$?%__sil_tmpSIL_materialize_temp__n$0:std::runtime_error const ); [line 38, column 11]\n n$2=_fun_std::runtime_error::runtime_error(&0$?%__sil_tmpSIL_materialize_temp__n$0:std::runtime_error const *,\"error\":char const *) [line 38, column 11]\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
"FN_deref_null_in_catch_bad#9297890526029657977.c83eec7c9ab8ce2e38ddbc08f8c3dfeb_4" -> "FN_deref_null_in_catch_bad#9297890526029657977.c83eec7c9ab8ce2e38ddbc08f8c3dfeb_5" ;
"FN_deref_null_in_catch_bad#9297890526029657977.c83eec7c9ab8ce2e38ddbc08f8c3dfeb_5" [label="5: Destruction(temporaries cleanup) \n n$3=_fun_std::runtime_error::runtime_error(&0$?%__sil_tmp__temp_construct_n$1:std::runtime_error*,&0$?%__sil_tmpSIL_materialize_temp__n$0:std::runtime_error const &) [line 38, column 11]\n n$4=_fun___infer_objc_cpp_throw(&0$?%__sil_tmp__temp_construct_n$1:std::runtime_error) [line 38, column 5]\n _=*&0$?%__sil_tmpSIL_materialize_temp__n$0:std::runtime_error const [line 38, column 37]\n n$6=_fun_std::runtime_error::~runtime_error(&0$?%__sil_tmpSIL_materialize_temp__n$0:std::runtime_error const *) injected virtual [line 38, column 37]\n " shape="box"]
[clang] destroy C++ temporaries Summary: Inject destructor calls to destroy a temporary when its lifetime ends. Reviewed By: mbouaziz Differential Revision: D15674209 fbshipit-source-id: 0f783a906
6 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
"FN_deref_null_in_catch_bad#9297890526029657977.c83eec7c9ab8ce2e38ddbc08f8c3dfeb_5" -> "FN_deref_null_in_catch_bad#9297890526029657977.c83eec7c9ab8ce2e38ddbc08f8c3dfeb_3" ;
"FN_deref_null_in_catch_bad#9297890526029657977.c83eec7c9ab8ce2e38ddbc08f8c3dfeb_5" -> "FN_deref_null_in_catch_bad#9297890526029657977.c83eec7c9ab8ce2e38ddbc08f8c3dfeb_6" [color="red" ];
"FN_deref_null_in_catch_bad#9297890526029657977.c83eec7c9ab8ce2e38ddbc08f8c3dfeb_6" [label="6: Return Stmt \n n$7=*&i:int* [line 40, column 13]\n n$8=*n$7:int [line 40, column 12]\n " shape="box"]
[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
[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
"FN_deref_null_in_catch_bad#9297890526029657977.c83eec7c9ab8ce2e38ddbc08f8c3dfeb_6" -> "FN_deref_null_in_catch_bad#9297890526029657977.c83eec7c9ab8ce2e38ddbc08f8c3dfeb_7" ;
"FN_deref_null_in_catch_bad#9297890526029657977.c83eec7c9ab8ce2e38ddbc08f8c3dfeb_7" [label="7: Return Stmt \n *&return:int=n$8 [line 40, column 5]\n " shape="box"]
[clang] basic support for exceptional control-flow Summary: This diff: - translates C++ `catch` blocks - adds an exceptional control-flow edge from the end of a `try` block to the beginning of a `catch` block This obviously doesn't reflect the way exceptions actually work, but I think it is better than what we have now. For one thing, we'll see/translate code inside `catch` blocks, which were opaque before. If Clang analyses don't want this behavior, they can simply use `ProcCfg.Normal` (which, up until this diff, behaved identically to `ProcCfg.Exceptional`. In the future, we can extend `trans_state` to track blocks that might throw an exception, and have each of these blocks transition to `catch` instead. Reviewed By: jvillard Differential Revision: D7814521 fbshipit-source-id: 67b86a6
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
"FN_deref_null_in_catch_bad#9297890526029657977.c83eec7c9ab8ce2e38ddbc08f8c3dfeb_7" -> "FN_deref_null_in_catch_bad#9297890526029657977.c83eec7c9ab8ce2e38ddbc08f8c3dfeb_2" ;
"FN_deref_null_in_catch_bad#9297890526029657977.c83eec7c9ab8ce2e38ddbc08f8c3dfeb_8" [label="8: DeclStmt \n VARIABLE_DECLARED(i:int*); [line 36, column 3]\n *&i:int*=null [line 36, column 3]\n " shape="box"]
[clang] basic support for exceptional control-flow Summary: This diff: - translates C++ `catch` blocks - adds an exceptional control-flow edge from the end of a `try` block to the beginning of a `catch` block This obviously doesn't reflect the way exceptions actually work, but I think it is better than what we have now. For one thing, we'll see/translate code inside `catch` blocks, which were opaque before. If Clang analyses don't want this behavior, they can simply use `ProcCfg.Normal` (which, up until this diff, behaved identically to `ProcCfg.Exceptional`. In the future, we can extend `trans_state` to track blocks that might throw an exception, and have each of these blocks transition to `catch` instead. Reviewed By: jvillard Differential Revision: D7814521 fbshipit-source-id: 67b86a6
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
"FN_deref_null_in_catch_bad#9297890526029657977.c83eec7c9ab8ce2e38ddbc08f8c3dfeb_8" -> "FN_deref_null_in_catch_bad#9297890526029657977.c83eec7c9ab8ce2e38ddbc08f8c3dfeb_4" ;
"FN_multiple_catches_bad#4595182522053295670.680a793e449c2d7439ff6441ca69fa98_1" [label="1: Start FN_multiple_catches_bad\nFormals: b:_Bool\nLocals: 0$?%__sil_tmp__temp_construct_n$2:std::length_error 0$?%__sil_tmpSIL_materialize_temp__n$1:std::length_error const 0$?%__sil_tmp__temp_construct_n$9:std::range_error 0$?%__sil_tmpSIL_materialize_temp__n$8:std::range_error const j:int* i:int* \n " color=yellow style=filled]
[clang] basic support for exceptional control-flow Summary: This diff: - translates C++ `catch` blocks - adds an exceptional control-flow edge from the end of a `try` block to the beginning of a `catch` block This obviously doesn't reflect the way exceptions actually work, but I think it is better than what we have now. For one thing, we'll see/translate code inside `catch` blocks, which were opaque before. If Clang analyses don't want this behavior, they can simply use `ProcCfg.Normal` (which, up until this diff, behaved identically to `ProcCfg.Exceptional`. In the future, we can extend `trans_state` to track blocks that might throw an exception, and have each of these blocks transition to `catch` instead. Reviewed By: jvillard Differential Revision: D7814521 fbshipit-source-id: 67b86a6
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
"FN_multiple_catches_bad#4595182522053295670.680a793e449c2d7439ff6441ca69fa98_1" -> "FN_multiple_catches_bad#4595182522053295670.680a793e449c2d7439ff6441ca69fa98_16" ;
[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
"FN_multiple_catches_bad#4595182522053295670.680a793e449c2d7439ff6441ca69fa98_2" [label="2: Exit FN_multiple_catches_bad \n " color=yellow style=filled]
[clang] basic support for exceptional control-flow Summary: This diff: - translates C++ `catch` blocks - adds an exceptional control-flow edge from the end of a `try` block to the beginning of a `catch` block This obviously doesn't reflect the way exceptions actually work, but I think it is better than what we have now. For one thing, we'll see/translate code inside `catch` blocks, which were opaque before. If Clang analyses don't want this behavior, they can simply use `ProcCfg.Normal` (which, up until this diff, behaved identically to `ProcCfg.Exceptional`. In the future, we can extend `trans_state` to track blocks that might throw an exception, and have each of these blocks transition to `catch` instead. Reviewed By: jvillard Differential Revision: D7814521 fbshipit-source-id: 67b86a6
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
"FN_multiple_catches_bad#4595182522053295670.680a793e449c2d7439ff6441ca69fa98_3" [label="3: Return Stmt \n *&return:int=0 [line 69, column 3]\n " shape="box"]
[clang] basic support for exceptional control-flow Summary: This diff: - translates C++ `catch` blocks - adds an exceptional control-flow edge from the end of a `try` block to the beginning of a `catch` block This obviously doesn't reflect the way exceptions actually work, but I think it is better than what we have now. For one thing, we'll see/translate code inside `catch` blocks, which were opaque before. If Clang analyses don't want this behavior, they can simply use `ProcCfg.Normal` (which, up until this diff, behaved identically to `ProcCfg.Exceptional`. In the future, we can extend `trans_state` to track blocks that might throw an exception, and have each of these blocks transition to `catch` instead. Reviewed By: jvillard Differential Revision: D7814521 fbshipit-source-id: 67b86a6
7 years ago
"FN_multiple_catches_bad#4595182522053295670.680a793e449c2d7439ff6441ca69fa98_3" -> "FN_multiple_catches_bad#4595182522053295670.680a793e449c2d7439ff6441ca69fa98_2" ;
[pdesc][refactor] ability to set normal and exceptional succs independently Summary: - more flexible API - less error-prone thanks to named parameters - also takes care of adjusting predecessors of the previous successors! This fixes some (probably harmless) bugs in the frontends. Reviewed By: dulmarod Differential Revision: D18573923 fbshipit-source-id: ad97b3607
5 years ago
"FN_multiple_catches_bad#4595182522053295670.680a793e449c2d7439ff6441ca69fa98_4" [label="4: + \n " ]
[clang] basic support for exceptional control-flow Summary: This diff: - translates C++ `catch` blocks - adds an exceptional control-flow edge from the end of a `try` block to the beginning of a `catch` block This obviously doesn't reflect the way exceptions actually work, but I think it is better than what we have now. For one thing, we'll see/translate code inside `catch` blocks, which were opaque before. If Clang analyses don't want this behavior, they can simply use `ProcCfg.Normal` (which, up until this diff, behaved identically to `ProcCfg.Exceptional`. In the future, we can extend `trans_state` to track blocks that might throw an exception, and have each of these blocks transition to `catch` instead. Reviewed By: jvillard Differential Revision: D7814521 fbshipit-source-id: 67b86a6
7 years ago
"FN_multiple_catches_bad#4595182522053295670.680a793e449c2d7439ff6441ca69fa98_4" -> "FN_multiple_catches_bad#4595182522053295670.680a793e449c2d7439ff6441ca69fa98_3" ;
[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
"FN_multiple_catches_bad#4595182522053295670.680a793e449c2d7439ff6441ca69fa98_4" -> "FN_multiple_catches_bad#4595182522053295670.680a793e449c2d7439ff6441ca69fa98_13" [color="red" ];
[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
"FN_multiple_catches_bad#4595182522053295670.680a793e449c2d7439ff6441ca69fa98_4" -> "FN_multiple_catches_bad#4595182522053295670.680a793e449c2d7439ff6441ca69fa98_11" [color="red" ];
[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
"FN_multiple_catches_bad#4595182522053295670.680a793e449c2d7439ff6441ca69fa98_5" [label="5: Prune (true branch, if) \n n$0=*&b:_Bool [line 59, column 9]\n PRUNE(n$0, true); [line 59, column 9]\n " shape="invhouse"]
[clang] basic support for exceptional control-flow Summary: This diff: - translates C++ `catch` blocks - adds an exceptional control-flow edge from the end of a `try` block to the beginning of a `catch` block This obviously doesn't reflect the way exceptions actually work, but I think it is better than what we have now. For one thing, we'll see/translate code inside `catch` blocks, which were opaque before. If Clang analyses don't want this behavior, they can simply use `ProcCfg.Normal` (which, up until this diff, behaved identically to `ProcCfg.Exceptional`. In the future, we can extend `trans_state` to track blocks that might throw an exception, and have each of these blocks transition to `catch` instead. Reviewed By: jvillard Differential Revision: D7814521 fbshipit-source-id: 67b86a6
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
"FN_multiple_catches_bad#4595182522053295670.680a793e449c2d7439ff6441ca69fa98_5" -> "FN_multiple_catches_bad#4595182522053295670.680a793e449c2d7439ff6441ca69fa98_7" ;
[cfg] run pre-analysis lazily in ondemand Summary: This also prints the CFGs *after* pre-analysis for individual procedures in infer-out/captured/<filename>/<proc>.dot. One can also look up the CFGs before pre-analysis in infer-out/captured/proc_cfgs_frontend.dot. Context: I want to add a pre-analysis that needs to look at proc attributes inter-procedurally. For this to make sense it has to happen *after* all of capture, and before analysis. Thus, this diff brings back the lazy running of the pre-analysis like in D15803492, except that we still make sure to run the pre-analyses systematically regardless of the checkers being run by running the pre-analysis from ondemand.ml. Also we don't need to re-introduce the "did_preanalysis" proc attribute for the same reason that the pre-analysis is now run once and for all by ondemand.ml (instead of each individual checker back in the days). This has the benefit of running the pre-analysis only when needed, and the drawback that several concurrent processes analysing the same proc descs will duplicate work. Since pre-analyses are supposed to be very fast I assume that neither is a big deal. If they become more expensive then the benefit gets bigger and the drawback is just the same as with regular analyses. Reviewed By: skcho Differential Revision: D18573920 fbshipit-source-id: de350eaef
5 years ago
"FN_multiple_catches_bad#4595182522053295670.680a793e449c2d7439ff6441ca69fa98_6" [label="6: Prune (false branch, if) \n n$0=*&b:_Bool [line 59, column 9]\n PRUNE(!n$0, false); [line 59, column 9]\n " shape="invhouse"]
[clang] basic support for exceptional control-flow Summary: This diff: - translates C++ `catch` blocks - adds an exceptional control-flow edge from the end of a `try` block to the beginning of a `catch` block This obviously doesn't reflect the way exceptions actually work, but I think it is better than what we have now. For one thing, we'll see/translate code inside `catch` blocks, which were opaque before. If Clang analyses don't want this behavior, they can simply use `ProcCfg.Normal` (which, up until this diff, behaved identically to `ProcCfg.Exceptional`. In the future, we can extend `trans_state` to track blocks that might throw an exception, and have each of these blocks transition to `catch` instead. Reviewed By: jvillard Differential Revision: D7814521 fbshipit-source-id: 67b86a6
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
"FN_multiple_catches_bad#4595182522053295670.680a793e449c2d7439ff6441ca69fa98_6" -> "FN_multiple_catches_bad#4595182522053295670.680a793e449c2d7439ff6441ca69fa98_9" ;
"FN_multiple_catches_bad#4595182522053295670.680a793e449c2d7439ff6441ca69fa98_7" [label="7: DeclStmt \n VARIABLE_DECLARED(0$?%__sil_tmpSIL_materialize_temp__n$1:std::length_error const ); [line 60, column 13]\n n$3=_fun_std::length_error::length_error(&0$?%__sil_tmpSIL_materialize_temp__n$1:std::length_error const *,\"error\":char const *) [line 60, column 13]\n " shape="box"]
[clang] basic support for exceptional control-flow Summary: This diff: - translates C++ `catch` blocks - adds an exceptional control-flow edge from the end of a `try` block to the beginning of a `catch` block This obviously doesn't reflect the way exceptions actually work, but I think it is better than what we have now. For one thing, we'll see/translate code inside `catch` blocks, which were opaque before. If Clang analyses don't want this behavior, they can simply use `ProcCfg.Normal` (which, up until this diff, behaved identically to `ProcCfg.Exceptional`. In the future, we can extend `trans_state` to track blocks that might throw an exception, and have each of these blocks transition to `catch` instead. Reviewed By: jvillard Differential Revision: D7814521 fbshipit-source-id: 67b86a6
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
"FN_multiple_catches_bad#4595182522053295670.680a793e449c2d7439ff6441ca69fa98_7" -> "FN_multiple_catches_bad#4595182522053295670.680a793e449c2d7439ff6441ca69fa98_8" ;
"FN_multiple_catches_bad#4595182522053295670.680a793e449c2d7439ff6441ca69fa98_8" [label="8: Destruction(temporaries cleanup) \n n$4=_fun_std::length_error::length_error(&0$?%__sil_tmp__temp_construct_n$2:std::length_error*,&0$?%__sil_tmpSIL_materialize_temp__n$1:std::length_error const &) [line 60, column 13]\n n$5=_fun___infer_objc_cpp_throw(&0$?%__sil_tmp__temp_construct_n$2:std::length_error) [line 60, column 7]\n _=*&0$?%__sil_tmpSIL_materialize_temp__n$1:std::length_error const [line 60, column 38]\n n$7=_fun_std::length_error::~length_error(&0$?%__sil_tmpSIL_materialize_temp__n$1:std::length_error const *) injected virtual [line 60, column 38]\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
"FN_multiple_catches_bad#4595182522053295670.680a793e449c2d7439ff6441ca69fa98_8" -> "FN_multiple_catches_bad#4595182522053295670.680a793e449c2d7439ff6441ca69fa98_4" ;
"FN_multiple_catches_bad#4595182522053295670.680a793e449c2d7439ff6441ca69fa98_9" [label="9: DeclStmt \n VARIABLE_DECLARED(0$?%__sil_tmpSIL_materialize_temp__n$8:std::range_error const ); [line 62, column 13]\n n$10=_fun_std::range_error::range_error(&0$?%__sil_tmpSIL_materialize_temp__n$8:std::range_error const *,\"error\":char const *) [line 62, column 13]\n " shape="box"]
[clang] destroy C++ temporaries Summary: Inject destructor calls to destroy a temporary when its lifetime ends. Reviewed By: mbouaziz Differential Revision: D15674209 fbshipit-source-id: 0f783a906
6 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
"FN_multiple_catches_bad#4595182522053295670.680a793e449c2d7439ff6441ca69fa98_9" -> "FN_multiple_catches_bad#4595182522053295670.680a793e449c2d7439ff6441ca69fa98_10" ;
"FN_multiple_catches_bad#4595182522053295670.680a793e449c2d7439ff6441ca69fa98_10" [label="10: Destruction(temporaries cleanup) \n n$11=_fun_std::range_error::range_error(&0$?%__sil_tmp__temp_construct_n$9:std::range_error*,&0$?%__sil_tmpSIL_materialize_temp__n$8:std::range_error const &) [line 62, column 13]\n n$12=_fun___infer_objc_cpp_throw(&0$?%__sil_tmp__temp_construct_n$9:std::range_error) [line 62, column 7]\n _=*&0$?%__sil_tmpSIL_materialize_temp__n$8:std::range_error const [line 62, column 37]\n n$14=_fun_std::range_error::~range_error(&0$?%__sil_tmpSIL_materialize_temp__n$8:std::range_error const *) injected virtual [line 62, column 37]\n " shape="box"]
[clang] basic support for exceptional control-flow Summary: This diff: - translates C++ `catch` blocks - adds an exceptional control-flow edge from the end of a `try` block to the beginning of a `catch` block This obviously doesn't reflect the way exceptions actually work, but I think it is better than what we have now. For one thing, we'll see/translate code inside `catch` blocks, which were opaque before. If Clang analyses don't want this behavior, they can simply use `ProcCfg.Normal` (which, up until this diff, behaved identically to `ProcCfg.Exceptional`. In the future, we can extend `trans_state` to track blocks that might throw an exception, and have each of these blocks transition to `catch` instead. Reviewed By: jvillard Differential Revision: D7814521 fbshipit-source-id: 67b86a6
7 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
"FN_multiple_catches_bad#4595182522053295670.680a793e449c2d7439ff6441ca69fa98_10" -> "FN_multiple_catches_bad#4595182522053295670.680a793e449c2d7439ff6441ca69fa98_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
"FN_multiple_catches_bad#4595182522053295670.680a793e449c2d7439ff6441ca69fa98_11" [label="11: Return Stmt \n n$16=*&i:int* [line 65, column 13]\n n$17=*n$16:int [line 65, column 12]\n " shape="box"]
[clang] basic support for exceptional control-flow Summary: This diff: - translates C++ `catch` blocks - adds an exceptional control-flow edge from the end of a `try` block to the beginning of a `catch` block This obviously doesn't reflect the way exceptions actually work, but I think it is better than what we have now. For one thing, we'll see/translate code inside `catch` blocks, which were opaque before. If Clang analyses don't want this behavior, they can simply use `ProcCfg.Normal` (which, up until this diff, behaved identically to `ProcCfg.Exceptional`. In the future, we can extend `trans_state` to track blocks that might throw an exception, and have each of these blocks transition to `catch` instead. Reviewed By: jvillard Differential Revision: D7814521 fbshipit-source-id: 67b86a6
7 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
"FN_multiple_catches_bad#4595182522053295670.680a793e449c2d7439ff6441ca69fa98_11" -> "FN_multiple_catches_bad#4595182522053295670.680a793e449c2d7439ff6441ca69fa98_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
"FN_multiple_catches_bad#4595182522053295670.680a793e449c2d7439ff6441ca69fa98_12" [label="12: Return Stmt \n *&return:int=n$17 [line 65, column 5]\n " shape="box"]
[clang] basic support for exceptional control-flow Summary: This diff: - translates C++ `catch` blocks - adds an exceptional control-flow edge from the end of a `try` block to the beginning of a `catch` block This obviously doesn't reflect the way exceptions actually work, but I think it is better than what we have now. For one thing, we'll see/translate code inside `catch` blocks, which were opaque before. If Clang analyses don't want this behavior, they can simply use `ProcCfg.Normal` (which, up until this diff, behaved identically to `ProcCfg.Exceptional`. In the future, we can extend `trans_state` to track blocks that might throw an exception, and have each of these blocks transition to `catch` instead. Reviewed By: jvillard Differential Revision: D7814521 fbshipit-source-id: 67b86a6
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
"FN_multiple_catches_bad#4595182522053295670.680a793e449c2d7439ff6441ca69fa98_12" -> "FN_multiple_catches_bad#4595182522053295670.680a793e449c2d7439ff6441ca69fa98_2" ;
"FN_multiple_catches_bad#4595182522053295670.680a793e449c2d7439ff6441ca69fa98_13" [label="13: Return Stmt \n n$18=*&j:int* [line 67, column 13]\n n$19=*n$18:int [line 67, column 12]\n " shape="box"]
[clang] basic support for exceptional control-flow Summary: This diff: - translates C++ `catch` blocks - adds an exceptional control-flow edge from the end of a `try` block to the beginning of a `catch` block This obviously doesn't reflect the way exceptions actually work, but I think it is better than what we have now. For one thing, we'll see/translate code inside `catch` blocks, which were opaque before. If Clang analyses don't want this behavior, they can simply use `ProcCfg.Normal` (which, up until this diff, behaved identically to `ProcCfg.Exceptional`. In the future, we can extend `trans_state` to track blocks that might throw an exception, and have each of these blocks transition to `catch` instead. Reviewed By: jvillard Differential Revision: D7814521 fbshipit-source-id: 67b86a6
7 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
"FN_multiple_catches_bad#4595182522053295670.680a793e449c2d7439ff6441ca69fa98_13" -> "FN_multiple_catches_bad#4595182522053295670.680a793e449c2d7439ff6441ca69fa98_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
"FN_multiple_catches_bad#4595182522053295670.680a793e449c2d7439ff6441ca69fa98_14" [label="14: Return Stmt \n *&return:int=n$19 [line 67, column 5]\n " shape="box"]
[clang] basic support for exceptional control-flow Summary: This diff: - translates C++ `catch` blocks - adds an exceptional control-flow edge from the end of a `try` block to the beginning of a `catch` block This obviously doesn't reflect the way exceptions actually work, but I think it is better than what we have now. For one thing, we'll see/translate code inside `catch` blocks, which were opaque before. If Clang analyses don't want this behavior, they can simply use `ProcCfg.Normal` (which, up until this diff, behaved identically to `ProcCfg.Exceptional`. In the future, we can extend `trans_state` to track blocks that might throw an exception, and have each of these blocks transition to `catch` instead. Reviewed By: jvillard Differential Revision: D7814521 fbshipit-source-id: 67b86a6
7 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
"FN_multiple_catches_bad#4595182522053295670.680a793e449c2d7439ff6441ca69fa98_14" -> "FN_multiple_catches_bad#4595182522053295670.680a793e449c2d7439ff6441ca69fa98_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
"FN_multiple_catches_bad#4595182522053295670.680a793e449c2d7439ff6441ca69fa98_15" [label="15: DeclStmt \n VARIABLE_DECLARED(j:int*); [line 57, column 3]\n *&j:int*=null [line 57, column 3]\n " shape="box"]
[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
[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
"FN_multiple_catches_bad#4595182522053295670.680a793e449c2d7439ff6441ca69fa98_15" -> "FN_multiple_catches_bad#4595182522053295670.680a793e449c2d7439ff6441ca69fa98_5" ;
"FN_multiple_catches_bad#4595182522053295670.680a793e449c2d7439ff6441ca69fa98_15" -> "FN_multiple_catches_bad#4595182522053295670.680a793e449c2d7439ff6441ca69fa98_6" ;
"FN_multiple_catches_bad#4595182522053295670.680a793e449c2d7439ff6441ca69fa98_16" [label="16: DeclStmt \n VARIABLE_DECLARED(i:int*); [line 56, column 3]\n *&i:int*=null [line 56, column 3]\n " shape="box"]
[clang] basic support for exceptional control-flow Summary: This diff: - translates C++ `catch` blocks - adds an exceptional control-flow edge from the end of a `try` block to the beginning of a `catch` block This obviously doesn't reflect the way exceptions actually work, but I think it is better than what we have now. For one thing, we'll see/translate code inside `catch` blocks, which were opaque before. If Clang analyses don't want this behavior, they can simply use `ProcCfg.Normal` (which, up until this diff, behaved identically to `ProcCfg.Exceptional`. In the future, we can extend `trans_state` to track blocks that might throw an exception, and have each of these blocks transition to `catch` instead. Reviewed By: jvillard Differential Revision: D7814521 fbshipit-source-id: 67b86a6
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
"FN_multiple_catches_bad#4595182522053295670.680a793e449c2d7439ff6441ca69fa98_16" -> "FN_multiple_catches_bad#4595182522053295670.680a793e449c2d7439ff6441ca69fa98_15" ;
"basic_throw_ok#10529188890980782893.c9e1b8dd080b2621cfca65612331859d_1" [label="1: Start basic_throw_ok\nFormals: \nLocals: 0$?%__sil_tmp__temp_construct_n$1:std::runtime_error 0$?%__sil_tmpSIL_materialize_temp__n$0:std::runtime_error const \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
"basic_throw_ok#10529188890980782893.c9e1b8dd080b2621cfca65612331859d_1" -> "basic_throw_ok#10529188890980782893.c9e1b8dd080b2621cfca65612331859d_3" ;
[cfg] run pre-analysis lazily in ondemand Summary: This also prints the CFGs *after* pre-analysis for individual procedures in infer-out/captured/<filename>/<proc>.dot. One can also look up the CFGs before pre-analysis in infer-out/captured/proc_cfgs_frontend.dot. Context: I want to add a pre-analysis that needs to look at proc attributes inter-procedurally. For this to make sense it has to happen *after* all of capture, and before analysis. Thus, this diff brings back the lazy running of the pre-analysis like in D15803492, except that we still make sure to run the pre-analyses systematically regardless of the checkers being run by running the pre-analysis from ondemand.ml. Also we don't need to re-introduce the "did_preanalysis" proc attribute for the same reason that the pre-analysis is now run once and for all by ondemand.ml (instead of each individual checker back in the days). This has the benefit of running the pre-analysis only when needed, and the drawback that several concurrent processes analysing the same proc descs will duplicate work. Since pre-analyses are supposed to be very fast I assume that neither is a big deal. If they become more expensive then the benefit gets bigger and the drawback is just the same as with regular analyses. Reviewed By: skcho Differential Revision: D18573920 fbshipit-source-id: de350eaef
5 years ago
"basic_throw_ok#10529188890980782893.c9e1b8dd080b2621cfca65612331859d_2" [label="2: Exit basic_throw_ok \n " color=yellow style=filled]
[clang] destroy C++ temporaries Summary: Inject destructor calls to destroy a temporary when its lifetime ends. Reviewed By: mbouaziz Differential Revision: D15674209 fbshipit-source-id: 0f783a906
6 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
"basic_throw_ok#10529188890980782893.c9e1b8dd080b2621cfca65612331859d_3" [label="3: DeclStmt \n VARIABLE_DECLARED(0$?%__sil_tmpSIL_materialize_temp__n$0:std::runtime_error const ); [line 27, column 31]\n n$2=_fun_std::runtime_error::runtime_error(&0$?%__sil_tmpSIL_materialize_temp__n$0:std::runtime_error const *,\"throwing!\":char const *) [line 27, column 31]\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
"basic_throw_ok#10529188890980782893.c9e1b8dd080b2621cfca65612331859d_3" -> "basic_throw_ok#10529188890980782893.c9e1b8dd080b2621cfca65612331859d_4" ;
"basic_throw_ok#10529188890980782893.c9e1b8dd080b2621cfca65612331859d_4" [label="4: Destruction(temporaries cleanup) \n n$3=_fun_std::runtime_error::runtime_error(&0$?%__sil_tmp__temp_construct_n$1:std::runtime_error*,&0$?%__sil_tmpSIL_materialize_temp__n$0:std::runtime_error const &) [line 27, column 31]\n n$4=_fun___infer_objc_cpp_throw(&0$?%__sil_tmp__temp_construct_n$1:std::runtime_error) [line 27, column 25]\n _=*&0$?%__sil_tmpSIL_materialize_temp__n$0:std::runtime_error const [line 27, column 61]\n n$6=_fun_std::runtime_error::~runtime_error(&0$?%__sil_tmpSIL_materialize_temp__n$0:std::runtime_error const *) injected virtual [line 27, column 61]\n " shape="box"]
[clang] destroy C++ temporaries Summary: Inject destructor calls to destroy a temporary when its lifetime ends. Reviewed By: mbouaziz Differential Revision: D15674209 fbshipit-source-id: 0f783a906
6 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
"basic_throw_ok#10529188890980782893.c9e1b8dd080b2621cfca65612331859d_4" -> "basic_throw_ok#10529188890980782893.c9e1b8dd080b2621cfca65612331859d_2" ;
Get rid of Declare_locals Reviewed By: jeremydubreil Differential Revision: D9234331 fbshipit-source-id: 70443eabe
6 years ago
"call_deref_with_null#4611966425999531792.6346543307e9a799421a89e451b917c2_1" [label="1: Start call_deref_with_null\nFormals: \nLocals: \n " color=yellow style=filled]
Translate C++ exceptions Reviewed By: akotulski Differential Revision: D3005619 fb-gh-sync-id: a64790b shipit-source-id: a64790b
9 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
"call_deref_with_null#4611966425999531792.6346543307e9a799421a89e451b917c2_1" -> "call_deref_with_null#4611966425999531792.6346543307e9a799421a89e451b917c2_3" ;
"call_deref_with_null#4611966425999531792.6346543307e9a799421a89e451b917c2_2" [label="2: Exit call_deref_with_null \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
[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
"call_deref_with_null#4611966425999531792.6346543307e9a799421a89e451b917c2_3" [label="3: Call _fun_deref_null \n n$0=_fun_deref_null(null:int*) [line 25, column 30]\n " shape="box"]
Translate C++ exceptions Reviewed By: akotulski Differential Revision: D3005619 fb-gh-sync-id: a64790b shipit-source-id: a64790b
9 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
"call_deref_with_null#4611966425999531792.6346543307e9a799421a89e451b917c2_3" -> "call_deref_with_null#4611966425999531792.6346543307e9a799421a89e451b917c2_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
"dead_deref_null_after_throw_ok#12025371096822526715.42d41c040f3a321bb94f60bf7b55d001_1" [label="1: Start dead_deref_null_after_throw_ok\nFormals: \nLocals: 0$?%__sil_tmp__temp_construct_n$3:std::runtime_error 0$?%__sil_tmpSIL_materialize_temp__n$2:std::runtime_error const i:int* \n " color=yellow style=filled]
[clang] basic support for exceptional control-flow Summary: This diff: - translates C++ `catch` blocks - adds an exceptional control-flow edge from the end of a `try` block to the beginning of a `catch` block This obviously doesn't reflect the way exceptions actually work, but I think it is better than what we have now. For one thing, we'll see/translate code inside `catch` blocks, which were opaque before. If Clang analyses don't want this behavior, they can simply use `ProcCfg.Normal` (which, up until this diff, behaved identically to `ProcCfg.Exceptional`. In the future, we can extend `trans_state` to track blocks that might throw an exception, and have each of these blocks transition to `catch` instead. Reviewed By: jvillard Differential Revision: D7814521 fbshipit-source-id: 67b86a6
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
"dead_deref_null_after_throw_ok#12025371096822526715.42d41c040f3a321bb94f60bf7b55d001_1" -> "dead_deref_null_after_throw_ok#12025371096822526715.42d41c040f3a321bb94f60bf7b55d001_7" ;
[cfg] run pre-analysis lazily in ondemand Summary: This also prints the CFGs *after* pre-analysis for individual procedures in infer-out/captured/<filename>/<proc>.dot. One can also look up the CFGs before pre-analysis in infer-out/captured/proc_cfgs_frontend.dot. Context: I want to add a pre-analysis that needs to look at proc attributes inter-procedurally. For this to make sense it has to happen *after* all of capture, and before analysis. Thus, this diff brings back the lazy running of the pre-analysis like in D15803492, except that we still make sure to run the pre-analyses systematically regardless of the checkers being run by running the pre-analysis from ondemand.ml. Also we don't need to re-introduce the "did_preanalysis" proc attribute for the same reason that the pre-analysis is now run once and for all by ondemand.ml (instead of each individual checker back in the days). This has the benefit of running the pre-analysis only when needed, and the drawback that several concurrent processes analysing the same proc descs will duplicate work. Since pre-analyses are supposed to be very fast I assume that neither is a big deal. If they become more expensive then the benefit gets bigger and the drawback is just the same as with regular analyses. Reviewed By: skcho Differential Revision: D18573920 fbshipit-source-id: de350eaef
5 years ago
"dead_deref_null_after_throw_ok#12025371096822526715.42d41c040f3a321bb94f60bf7b55d001_2" [label="2: Exit dead_deref_null_after_throw_ok \n " color=yellow style=filled]
[clang] basic support for exceptional control-flow Summary: This diff: - translates C++ `catch` blocks - adds an exceptional control-flow edge from the end of a `try` block to the beginning of a `catch` block This obviously doesn't reflect the way exceptions actually work, but I think it is better than what we have now. For one thing, we'll see/translate code inside `catch` blocks, which were opaque before. If Clang analyses don't want this behavior, they can simply use `ProcCfg.Normal` (which, up until this diff, behaved identically to `ProcCfg.Exceptional`. In the future, we can extend `trans_state` to track blocks that might throw an exception, and have each of these blocks transition to `catch` instead. Reviewed By: jvillard Differential Revision: D7814521 fbshipit-source-id: 67b86a6
7 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
"dead_deref_null_after_throw_ok#12025371096822526715.42d41c040f3a321bb94f60bf7b55d001_3" [label="3: Return Stmt \n n$0=*&i:int* [line 32, column 11]\n n$1=*n$0:int [line 32, column 10]\n " shape="box"]
[clang] basic support for exceptional control-flow Summary: This diff: - translates C++ `catch` blocks - adds an exceptional control-flow edge from the end of a `try` block to the beginning of a `catch` block This obviously doesn't reflect the way exceptions actually work, but I think it is better than what we have now. For one thing, we'll see/translate code inside `catch` blocks, which were opaque before. If Clang analyses don't want this behavior, they can simply use `ProcCfg.Normal` (which, up until this diff, behaved identically to `ProcCfg.Exceptional`. In the future, we can extend `trans_state` to track blocks that might throw an exception, and have each of these blocks transition to `catch` instead. Reviewed By: jvillard Differential Revision: D7814521 fbshipit-source-id: 67b86a6
7 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
"dead_deref_null_after_throw_ok#12025371096822526715.42d41c040f3a321bb94f60bf7b55d001_3" -> "dead_deref_null_after_throw_ok#12025371096822526715.42d41c040f3a321bb94f60bf7b55d001_4" ;
"dead_deref_null_after_throw_ok#12025371096822526715.42d41c040f3a321bb94f60bf7b55d001_4" [label="4: Return Stmt \n *&return:int=n$1 [line 32, column 3]\n " shape="box"]
[clang] basic support for exceptional control-flow Summary: This diff: - translates C++ `catch` blocks - adds an exceptional control-flow edge from the end of a `try` block to the beginning of a `catch` block This obviously doesn't reflect the way exceptions actually work, but I think it is better than what we have now. For one thing, we'll see/translate code inside `catch` blocks, which were opaque before. If Clang analyses don't want this behavior, they can simply use `ProcCfg.Normal` (which, up until this diff, behaved identically to `ProcCfg.Exceptional`. In the future, we can extend `trans_state` to track blocks that might throw an exception, and have each of these blocks transition to `catch` instead. Reviewed By: jvillard Differential Revision: D7814521 fbshipit-source-id: 67b86a6
7 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
"dead_deref_null_after_throw_ok#12025371096822526715.42d41c040f3a321bb94f60bf7b55d001_4" -> "dead_deref_null_after_throw_ok#12025371096822526715.42d41c040f3a321bb94f60bf7b55d001_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
"dead_deref_null_after_throw_ok#12025371096822526715.42d41c040f3a321bb94f60bf7b55d001_5" [label="5: DeclStmt \n VARIABLE_DECLARED(0$?%__sil_tmpSIL_materialize_temp__n$2:std::runtime_error const ); [line 31, column 9]\n n$4=_fun_std::runtime_error::runtime_error(&0$?%__sil_tmpSIL_materialize_temp__n$2:std::runtime_error const *,\"throwing!\":char const *) [line 31, column 9]\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
"dead_deref_null_after_throw_ok#12025371096822526715.42d41c040f3a321bb94f60bf7b55d001_5" -> "dead_deref_null_after_throw_ok#12025371096822526715.42d41c040f3a321bb94f60bf7b55d001_6" ;
"dead_deref_null_after_throw_ok#12025371096822526715.42d41c040f3a321bb94f60bf7b55d001_6" [label="6: Destruction(temporaries cleanup) \n n$5=_fun_std::runtime_error::runtime_error(&0$?%__sil_tmp__temp_construct_n$3:std::runtime_error*,&0$?%__sil_tmpSIL_materialize_temp__n$2:std::runtime_error const &) [line 31, column 9]\n n$6=_fun___infer_objc_cpp_throw(&0$?%__sil_tmp__temp_construct_n$3:std::runtime_error) [line 31, column 3]\n _=*&0$?%__sil_tmpSIL_materialize_temp__n$2:std::runtime_error const [line 31, column 39]\n n$8=_fun_std::runtime_error::~runtime_error(&0$?%__sil_tmpSIL_materialize_temp__n$2:std::runtime_error const *) injected virtual [line 31, column 39]\n " shape="box"]
[clang] basic support for exceptional control-flow Summary: This diff: - translates C++ `catch` blocks - adds an exceptional control-flow edge from the end of a `try` block to the beginning of a `catch` block This obviously doesn't reflect the way exceptions actually work, but I think it is better than what we have now. For one thing, we'll see/translate code inside `catch` blocks, which were opaque before. If Clang analyses don't want this behavior, they can simply use `ProcCfg.Normal` (which, up until this diff, behaved identically to `ProcCfg.Exceptional`. In the future, we can extend `trans_state` to track blocks that might throw an exception, and have each of these blocks transition to `catch` instead. Reviewed By: jvillard Differential Revision: D7814521 fbshipit-source-id: 67b86a6
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
"dead_deref_null_after_throw_ok#12025371096822526715.42d41c040f3a321bb94f60bf7b55d001_6" -> "dead_deref_null_after_throw_ok#12025371096822526715.42d41c040f3a321bb94f60bf7b55d001_3" ;
"dead_deref_null_after_throw_ok#12025371096822526715.42d41c040f3a321bb94f60bf7b55d001_7" [label="7: DeclStmt \n VARIABLE_DECLARED(i:int*); [line 30, column 3]\n *&i:int*=null [line 30, column 3]\n " shape="box"]
[clang] destroy C++ temporaries Summary: Inject destructor calls to destroy a temporary when its lifetime ends. Reviewed By: mbouaziz Differential Revision: D15674209 fbshipit-source-id: 0f783a906
6 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
"dead_deref_null_after_throw_ok#12025371096822526715.42d41c040f3a321bb94f60bf7b55d001_7" -> "dead_deref_null_after_throw_ok#12025371096822526715.42d41c040f3a321bb94f60bf7b55d001_5" ;
Get rid of Declare_locals Reviewed By: jeremydubreil Differential Revision: D9234331 fbshipit-source-id: 70443eabe
6 years ago
"deref#13506892413034678690.824465c4193ad2288eb512b1083edab3_1" [label="1: Start deref\nFormals: p:int*\nLocals: \n " color=yellow style=filled]
Translate C++ exceptions Reviewed By: akotulski Differential Revision: D3005619 fb-gh-sync-id: a64790b shipit-source-id: a64790b
9 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
"deref#13506892413034678690.824465c4193ad2288eb512b1083edab3_1" -> "deref#13506892413034678690.824465c4193ad2288eb512b1083edab3_6" ;
[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
"deref#13506892413034678690.824465c4193ad2288eb512b1083edab3_2" [label="2: Exit deref \n " color=yellow style=filled]
Translate C++ exceptions Reviewed By: akotulski Differential Revision: D3005619 fb-gh-sync-id: a64790b shipit-source-id: a64790b
9 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
"deref#13506892413034678690.824465c4193ad2288eb512b1083edab3_3" [label="3: Return Stmt \n n$0=*&p:int* [line 15, column 11]\n n$1=*n$0:int [line 15, column 10]\n " shape="box"]
Translate C++ exceptions Reviewed By: akotulski Differential Revision: D3005619 fb-gh-sync-id: a64790b shipit-source-id: a64790b
9 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
"deref#13506892413034678690.824465c4193ad2288eb512b1083edab3_3" -> "deref#13506892413034678690.824465c4193ad2288eb512b1083edab3_4" ;
"deref#13506892413034678690.824465c4193ad2288eb512b1083edab3_4" [label="4: Return Stmt \n *&return:int=n$1 [line 15, column 3]\n " shape="box"]
Translate C++ exceptions Reviewed By: akotulski Differential Revision: D3005619 fb-gh-sync-id: a64790b shipit-source-id: a64790b
9 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
"deref#13506892413034678690.824465c4193ad2288eb512b1083edab3_4" -> "deref#13506892413034678690.824465c4193ad2288eb512b1083edab3_2" ;
"deref#13506892413034678690.824465c4193ad2288eb512b1083edab3_5" [label="5: + \n " ]
Translate C++ exceptions Reviewed By: akotulski Differential Revision: D3005619 fb-gh-sync-id: a64790b shipit-source-id: a64790b
9 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
"deref#13506892413034678690.824465c4193ad2288eb512b1083edab3_5" -> "deref#13506892413034678690.824465c4193ad2288eb512b1083edab3_3" ;
"deref#13506892413034678690.824465c4193ad2288eb512b1083edab3_6" [label="6: BinaryOperatorStmt: EQ \n n$2=*&p:int* [line 12, column 7]\n " shape="box"]
Translate C++ exceptions Reviewed By: akotulski Differential Revision: D3005619 fb-gh-sync-id: a64790b shipit-source-id: a64790b
9 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
"deref#13506892413034678690.824465c4193ad2288eb512b1083edab3_6" -> "deref#13506892413034678690.824465c4193ad2288eb512b1083edab3_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
"deref#13506892413034678690.824465c4193ad2288eb512b1083edab3_6" -> "deref#13506892413034678690.824465c4193ad2288eb512b1083edab3_8" ;
[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
"deref#13506892413034678690.824465c4193ad2288eb512b1083edab3_7" [label="7: Prune (true branch, if) \n PRUNE((n$2 == null), true); [line 12, column 7]\n " shape="invhouse"]
"deref#13506892413034678690.824465c4193ad2288eb512b1083edab3_7" -> "deref#13506892413034678690.824465c4193ad2288eb512b1083edab3_9" ;
"deref#13506892413034678690.824465c4193ad2288eb512b1083edab3_8" [label="8: Prune (false branch, if) \n PRUNE(!(n$2 == null), false); [line 12, column 7]\n " shape="invhouse"]
Translate C++ exceptions Reviewed By: akotulski Differential Revision: D3005619 fb-gh-sync-id: a64790b shipit-source-id: a64790b
9 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
"deref#13506892413034678690.824465c4193ad2288eb512b1083edab3_8" -> "deref#13506892413034678690.824465c4193ad2288eb512b1083edab3_5" ;
"deref#13506892413034678690.824465c4193ad2288eb512b1083edab3_9" [label="9: ObjCCPPThrow \n n$3=_fun___infer_objc_cpp_throw(\"Null pointer!\":char const *) [line 13, column 5]\n " shape="box"]
Translate C++ exceptions Reviewed By: akotulski Differential Revision: D3005619 fb-gh-sync-id: a64790b shipit-source-id: a64790b
9 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
"deref#13506892413034678690.824465c4193ad2288eb512b1083edab3_9" -> "deref#13506892413034678690.824465c4193ad2288eb512b1083edab3_5" ;
Get rid of Declare_locals Reviewed By: jeremydubreil Differential Revision: D9234331 fbshipit-source-id: 70443eabe
6 years ago
"deref_null#11536394632240553702.ea4eed042da22ab7ceb619ec1b7f73bb_1" [label="1: Start deref_null\nFormals: p:int*\nLocals: \n " color=yellow style=filled]
Translate C++ exceptions Reviewed By: akotulski Differential Revision: D3005619 fb-gh-sync-id: a64790b shipit-source-id: a64790b
9 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
"deref_null#11536394632240553702.ea4eed042da22ab7ceb619ec1b7f73bb_1" -> "deref_null#11536394632240553702.ea4eed042da22ab7ceb619ec1b7f73bb_3" ;
"deref_null#11536394632240553702.ea4eed042da22ab7ceb619ec1b7f73bb_2" [label="2: Exit deref_null \n " color=yellow style=filled]
Translate C++ exceptions Reviewed By: akotulski Differential Revision: D3005619 fb-gh-sync-id: a64790b shipit-source-id: a64790b
9 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
"deref_null#11536394632240553702.ea4eed042da22ab7ceb619ec1b7f73bb_3" [label="3: Return Stmt \n n$0=*&p:int* [line 20, column 13]\n n$1=*n$0:int [line 20, column 12]\n " shape="box"]
Translate C++ exceptions Reviewed By: akotulski Differential Revision: D3005619 fb-gh-sync-id: a64790b shipit-source-id: a64790b
9 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
"deref_null#11536394632240553702.ea4eed042da22ab7ceb619ec1b7f73bb_3" -> "deref_null#11536394632240553702.ea4eed042da22ab7ceb619ec1b7f73bb_4" ;
"deref_null#11536394632240553702.ea4eed042da22ab7ceb619ec1b7f73bb_4" [label="4: Return Stmt \n *&return:int=n$1 [line 20, column 5]\n " shape="box"]
"deref_null#11536394632240553702.ea4eed042da22ab7ceb619ec1b7f73bb_4" -> "deref_null#11536394632240553702.ea4eed042da22ab7ceb619ec1b7f73bb_2" ;
Get rid of Declare_locals Reviewed By: jeremydubreil Differential Revision: D9234331 fbshipit-source-id: 70443eabe
6 years ago
"main.fad58de7366495db4650cfefac2fcd61_1" [label="1: Start main\nFormals: \nLocals: \n " color=yellow style=filled]
[debug] print procedures in alphabetical order in cfgs Summary: When looking at large CFGs, at least in `xdot`, it's often difficult to find the procedure you're looking for. Sorting the proc names puts them in alphabetical order, which makes searching one procedure easier. Reviewed By: mbouaziz Differential Revision: D7758521 fbshipit-source-id: 8e9997f
7 years ago
"main.fad58de7366495db4650cfefac2fcd61_1" -> "main.fad58de7366495db4650cfefac2fcd61_3" ;
"main.fad58de7366495db4650cfefac2fcd61_2" [label="2: Exit main \n " color=yellow style=filled]
[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
"main.fad58de7366495db4650cfefac2fcd61_3" [label="3: Return Stmt \n n$0=_fun_deref(null:int*) [line 74, column 12]\n " shape="box"]
[debug] print procedures in alphabetical order in cfgs Summary: When looking at large CFGs, at least in `xdot`, it's often difficult to find the procedure you're looking for. Sorting the proc names puts them in alphabetical order, which makes searching one procedure easier. Reviewed By: mbouaziz Differential Revision: D7758521 fbshipit-source-id: 8e9997f
7 years ago
[clang] 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
"main.fad58de7366495db4650cfefac2fcd61_3" -> "main.fad58de7366495db4650cfefac2fcd61_4" ;
"main.fad58de7366495db4650cfefac2fcd61_4" [label="4: Return Stmt \n *&return:int=n$0 [line 74, column 5]\n " shape="box"]
[clang] basic support for exceptional control-flow Summary: This diff: - translates C++ `catch` blocks - adds an exceptional control-flow edge from the end of a `try` block to the beginning of a `catch` block This obviously doesn't reflect the way exceptions actually work, but I think it is better than what we have now. For one thing, we'll see/translate code inside `catch` blocks, which were opaque before. If Clang analyses don't want this behavior, they can simply use `ProcCfg.Normal` (which, up until this diff, behaved identically to `ProcCfg.Exceptional`. In the future, we can extend `trans_state` to track blocks that might throw an exception, and have each of these blocks transition to `catch` instead. Reviewed By: jvillard Differential Revision: D7814521 fbshipit-source-id: 67b86a6
7 years ago
"main.fad58de7366495db4650cfefac2fcd61_4" -> "main.fad58de7366495db4650cfefac2fcd61_2" ;
[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
"main.fad58de7366495db4650cfefac2fcd61_5" [label="5: Return Stmt \n *&return:int=-1 [line 76, column 5]\n " shape="box"]
"main.fad58de7366495db4650cfefac2fcd61_5" -> "main.fad58de7366495db4650cfefac2fcd61_2" ;
Translate C++ exceptions Reviewed By: akotulski Differential Revision: D3005619 fb-gh-sync-id: a64790b shipit-source-id: a64790b
9 years ago
}