|
|
|
|
/* @generated */
|
|
|
|
|
digraph cfg {
|
|
|
|
|
"foo_int#class_specialization#18011277194514159170.29412bbb7345cd5150bdd3239c145d19_1" [label="1: Start class_specialization::foo_int\nFormals: \nLocals: z:int b:class_specialization::Derived<int> \n DECLARE_LOCALS(&return,&z,&b); [line 32, column 1]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"foo_int#class_specialization#18011277194514159170.29412bbb7345cd5150bdd3239c145d19_1" -> "foo_int#class_specialization#18011277194514159170.29412bbb7345cd5150bdd3239c145d19_5" ;
|
|
|
|
|
"foo_int#class_specialization#18011277194514159170.29412bbb7345cd5150bdd3239c145d19_2" [label="2: Exit class_specialization::foo_int \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
[clang] enforce that `instruction` always returns one SIL expression
Summary:
Previously, the type of `trans_result` contained a list of SIL expressions.
However, most of the time we expect to get exactly one, and getting a different
number is a soft(!) error, usually returning `-1`.
This splits `trans_result` into `control`, which contains the information
needed for temporary computation (hence when we don't necessarily know the
return value yet), and a new version of `trans_result` that includes `control`,
the previous `exps` list but replaced by a single `return` expression instead,
and a couple other values that made sense to move out of `control`. This allows
some flexibility in the frontend compared to enforcing exactly one return
expression always: if they are not known yet we stick to `control` instead (see
eg `compute_controls_to_parent`).
This creates more garbage temporary identifiers, however they do not show up in
the final cfg. Instead, we see that temporary IDs are now often not
consecutive...
The most painful complication is in the treatment of `DeclRefExpr`, which was
actually returning *two* expressions: the method name and the `this` object.
Now the method name is a separate (optional) field in `trans_result`.
Reviewed By: mbouaziz
Differential Revision: D7881088
fbshipit-source-id: 41ad3b5
7 years ago
|
|
|
"foo_int#class_specialization#18011277194514159170.29412bbb7345cd5150bdd3239c145d19_3" [label="3: DeclStmt \n n$1=*&b.x:int [line 35, column 15]\n *&z:int=(1 / n$1) [line 35, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"foo_int#class_specialization#18011277194514159170.29412bbb7345cd5150bdd3239c145d19_3" -> "foo_int#class_specialization#18011277194514159170.29412bbb7345cd5150bdd3239c145d19_2" ;
|
[clang] enforce that `instruction` always returns one SIL expression
Summary:
Previously, the type of `trans_result` contained a list of SIL expressions.
However, most of the time we expect to get exactly one, and getting a different
number is a soft(!) error, usually returning `-1`.
This splits `trans_result` into `control`, which contains the information
needed for temporary computation (hence when we don't necessarily know the
return value yet), and a new version of `trans_result` that includes `control`,
the previous `exps` list but replaced by a single `return` expression instead,
and a couple other values that made sense to move out of `control`. This allows
some flexibility in the frontend compared to enforcing exactly one return
expression always: if they are not known yet we stick to `control` instead (see
eg `compute_controls_to_parent`).
This creates more garbage temporary identifiers, however they do not show up in
the final cfg. Instead, we see that temporary IDs are now often not
consecutive...
The most painful complication is in the treatment of `DeclRefExpr`, which was
actually returning *two* expressions: the method name and the `this` object.
Now the method name is a separate (optional) field in `trans_result`.
Reviewed By: mbouaziz
Differential Revision: D7881088
fbshipit-source-id: 41ad3b5
7 years ago
|
|
|
"foo_int#class_specialization#18011277194514159170.29412bbb7345cd5150bdd3239c145d19_4" [label="4: Call _fun_class_specialization::Derived<int>_foo \n _=*&b:class_specialization::Derived<int> [line 34, column 3]\n n$3=_fun_class_specialization::Derived<int>_foo(&b:class_specialization::Derived<int>&,0:int) [line 34, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"foo_int#class_specialization#18011277194514159170.29412bbb7345cd5150bdd3239c145d19_4" -> "foo_int#class_specialization#18011277194514159170.29412bbb7345cd5150bdd3239c145d19_3" ;
|
[clang] enforce that `instruction` always returns one SIL expression
Summary:
Previously, the type of `trans_result` contained a list of SIL expressions.
However, most of the time we expect to get exactly one, and getting a different
number is a soft(!) error, usually returning `-1`.
This splits `trans_result` into `control`, which contains the information
needed for temporary computation (hence when we don't necessarily know the
return value yet), and a new version of `trans_result` that includes `control`,
the previous `exps` list but replaced by a single `return` expression instead,
and a couple other values that made sense to move out of `control`. This allows
some flexibility in the frontend compared to enforcing exactly one return
expression always: if they are not known yet we stick to `control` instead (see
eg `compute_controls_to_parent`).
This creates more garbage temporary identifiers, however they do not show up in
the final cfg. Instead, we see that temporary IDs are now often not
consecutive...
The most painful complication is in the treatment of `DeclRefExpr`, which was
actually returning *two* expressions: the method name and the `this` object.
Now the method name is a separate (optional) field in `trans_result`.
Reviewed By: mbouaziz
Differential Revision: D7881088
fbshipit-source-id: 41ad3b5
7 years ago
|
|
|
"foo_int#class_specialization#18011277194514159170.29412bbb7345cd5150bdd3239c145d19_5" [label="5: DeclStmt \n n$4=_fun_class_specialization::Derived<int>_Derived(&b:class_specialization::Derived<int>*) [line 33, column 16]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"foo_int#class_specialization#18011277194514159170.29412bbb7345cd5150bdd3239c145d19_5" -> "foo_int#class_specialization#18011277194514159170.29412bbb7345cd5150bdd3239c145d19_4" ;
|
|
|
|
|
"foo_intptr#class_specialization#3914514069521239538.096096ddd8eb9462872f535952d6e0a5_1" [label="1: Start class_specialization::foo_intptr\nFormals: \nLocals: x:int b:class_specialization::Derived<int*> \n DECLARE_LOCALS(&return,&x,&b); [line 26, column 1]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"foo_intptr#class_specialization#3914514069521239538.096096ddd8eb9462872f535952d6e0a5_1" -> "foo_intptr#class_specialization#3914514069521239538.096096ddd8eb9462872f535952d6e0a5_5" ;
|
|
|
|
|
"foo_intptr#class_specialization#3914514069521239538.096096ddd8eb9462872f535952d6e0a5_2" [label="2: Exit class_specialization::foo_intptr \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
[clang] enforce that `instruction` always returns one SIL expression
Summary:
Previously, the type of `trans_result` contained a list of SIL expressions.
However, most of the time we expect to get exactly one, and getting a different
number is a soft(!) error, usually returning `-1`.
This splits `trans_result` into `control`, which contains the information
needed for temporary computation (hence when we don't necessarily know the
return value yet), and a new version of `trans_result` that includes `control`,
the previous `exps` list but replaced by a single `return` expression instead,
and a couple other values that made sense to move out of `control`. This allows
some flexibility in the frontend compared to enforcing exactly one return
expression always: if they are not known yet we stick to `control` instead (see
eg `compute_controls_to_parent`).
This creates more garbage temporary identifiers, however they do not show up in
the final cfg. Instead, we see that temporary IDs are now often not
consecutive...
The most painful complication is in the treatment of `DeclRefExpr`, which was
actually returning *two* expressions: the method name and the `this` object.
Now the method name is a separate (optional) field in `trans_result`.
Reviewed By: mbouaziz
Differential Revision: D7881088
fbshipit-source-id: 41ad3b5
7 years ago
|
|
|
"foo_intptr#class_specialization#3914514069521239538.096096ddd8eb9462872f535952d6e0a5_3" [label="3: DeclStmt \n n$1=*&b.x:int* [line 29, column 12]\n n$2=*n$1:int [line 29, column 11]\n *&x:int=n$2 [line 29, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"foo_intptr#class_specialization#3914514069521239538.096096ddd8eb9462872f535952d6e0a5_3" -> "foo_intptr#class_specialization#3914514069521239538.096096ddd8eb9462872f535952d6e0a5_2" ;
|
[clang] enforce that `instruction` always returns one SIL expression
Summary:
Previously, the type of `trans_result` contained a list of SIL expressions.
However, most of the time we expect to get exactly one, and getting a different
number is a soft(!) error, usually returning `-1`.
This splits `trans_result` into `control`, which contains the information
needed for temporary computation (hence when we don't necessarily know the
return value yet), and a new version of `trans_result` that includes `control`,
the previous `exps` list but replaced by a single `return` expression instead,
and a couple other values that made sense to move out of `control`. This allows
some flexibility in the frontend compared to enforcing exactly one return
expression always: if they are not known yet we stick to `control` instead (see
eg `compute_controls_to_parent`).
This creates more garbage temporary identifiers, however they do not show up in
the final cfg. Instead, we see that temporary IDs are now often not
consecutive...
The most painful complication is in the treatment of `DeclRefExpr`, which was
actually returning *two* expressions: the method name and the `this` object.
Now the method name is a separate (optional) field in `trans_result`.
Reviewed By: mbouaziz
Differential Revision: D7881088
fbshipit-source-id: 41ad3b5
7 years ago
|
|
|
"foo_intptr#class_specialization#3914514069521239538.096096ddd8eb9462872f535952d6e0a5_4" [label="4: Call _fun_class_specialization::Derived<int*>_foo2 \n _=*&b:class_specialization::Derived<int*> [line 28, column 3]\n n$4=_fun_class_specialization::Derived<int*>_foo2(&b:class_specialization::Derived<int*>&,null:int*) [line 28, column 3]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"foo_intptr#class_specialization#3914514069521239538.096096ddd8eb9462872f535952d6e0a5_4" -> "foo_intptr#class_specialization#3914514069521239538.096096ddd8eb9462872f535952d6e0a5_3" ;
|
[clang] enforce that `instruction` always returns one SIL expression
Summary:
Previously, the type of `trans_result` contained a list of SIL expressions.
However, most of the time we expect to get exactly one, and getting a different
number is a soft(!) error, usually returning `-1`.
This splits `trans_result` into `control`, which contains the information
needed for temporary computation (hence when we don't necessarily know the
return value yet), and a new version of `trans_result` that includes `control`,
the previous `exps` list but replaced by a single `return` expression instead,
and a couple other values that made sense to move out of `control`. This allows
some flexibility in the frontend compared to enforcing exactly one return
expression always: if they are not known yet we stick to `control` instead (see
eg `compute_controls_to_parent`).
This creates more garbage temporary identifiers, however they do not show up in
the final cfg. Instead, we see that temporary IDs are now often not
consecutive...
The most painful complication is in the treatment of `DeclRefExpr`, which was
actually returning *two* expressions: the method name and the `this` object.
Now the method name is a separate (optional) field in `trans_result`.
Reviewed By: mbouaziz
Differential Revision: D7881088
fbshipit-source-id: 41ad3b5
7 years ago
|
|
|
"foo_intptr#class_specialization#3914514069521239538.096096ddd8eb9462872f535952d6e0a5_5" [label="5: DeclStmt \n n$5=_fun_class_specialization::Derived<int*>_Derived(&b:class_specialization::Derived<int*>*) [line 27, column 17]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"foo_intptr#class_specialization#3914514069521239538.096096ddd8eb9462872f535952d6e0a5_5" -> "foo_intptr#class_specialization#3914514069521239538.096096ddd8eb9462872f535952d6e0a5_4" ;
|
|
|
|
|
"Base#Base<int*>#class_specialization#{14101392445423095049}.4481221d683f8e54c4527519cddc792a_1" [label="1: Start class_specialization::Base<int*>_Base\nFormals: this:class_specialization::Base<int*>*\nLocals: \n DECLARE_LOCALS(&return); [line 12, column 8]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"Base#Base<int*>#class_specialization#{14101392445423095049}.4481221d683f8e54c4527519cddc792a_1" -> "Base#Base<int*>#class_specialization#{14101392445423095049}.4481221d683f8e54c4527519cddc792a_2" ;
|
|
|
|
|
"Base#Base<int*>#class_specialization#{14101392445423095049}.4481221d683f8e54c4527519cddc792a_2" [label="2: Exit class_specialization::Base<int*>_Base \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"Base#Base<int>#class_specialization#{16658552199303145313}.b6aa2df9eb4873c08c322ab298261cf8_1" [label="1: Start class_specialization::Base<int>_Base\nFormals: this:class_specialization::Base<int>*\nLocals: \n DECLARE_LOCALS(&return); [line 12, column 8]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"Base#Base<int>#class_specialization#{16658552199303145313}.b6aa2df9eb4873c08c322ab298261cf8_1" -> "Base#Base<int>#class_specialization#{16658552199303145313}.b6aa2df9eb4873c08c322ab298261cf8_2" ;
|
|
|
|
|
"Base#Base<int>#class_specialization#{16658552199303145313}.b6aa2df9eb4873c08c322ab298261cf8_2" [label="2: Exit class_specialization::Base<int>_Base \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"Derived#Derived<int*>#class_specialization#{6947111178756325946}.2484a8b63b0d0003a390b6e57428fee2_1" [label="1: Start class_specialization::Derived<int*>_Derived\nFormals: this:class_specialization::Derived<int*>*\nLocals: \n DECLARE_LOCALS(&return); [line 22, column 8]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"Derived#Derived<int*>#class_specialization#{6947111178756325946}.2484a8b63b0d0003a390b6e57428fee2_1" -> "Derived#Derived<int*>#class_specialization#{6947111178756325946}.2484a8b63b0d0003a390b6e57428fee2_3" ;
|
|
|
|
|
"Derived#Derived<int*>#class_specialization#{6947111178756325946}.2484a8b63b0d0003a390b6e57428fee2_2" [label="2: Exit class_specialization::Derived<int*>_Derived \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
[clang] enforce that `instruction` always returns one SIL expression
Summary:
Previously, the type of `trans_result` contained a list of SIL expressions.
However, most of the time we expect to get exactly one, and getting a different
number is a soft(!) error, usually returning `-1`.
This splits `trans_result` into `control`, which contains the information
needed for temporary computation (hence when we don't necessarily know the
return value yet), and a new version of `trans_result` that includes `control`,
the previous `exps` list but replaced by a single `return` expression instead,
and a couple other values that made sense to move out of `control`. This allows
some flexibility in the frontend compared to enforcing exactly one return
expression always: if they are not known yet we stick to `control` instead (see
eg `compute_controls_to_parent`).
This creates more garbage temporary identifiers, however they do not show up in
the final cfg. Instead, we see that temporary IDs are now often not
consecutive...
The most painful complication is in the treatment of `DeclRefExpr`, which was
actually returning *two* expressions: the method name and the `this` object.
Now the method name is a separate (optional) field in `trans_result`.
Reviewed By: mbouaziz
Differential Revision: D7881088
fbshipit-source-id: 41ad3b5
7 years ago
|
|
|
"Derived#Derived<int*>#class_specialization#{6947111178756325946}.2484a8b63b0d0003a390b6e57428fee2_3" [label="3: Constructor Init \n n$2=*&this:class_specialization::Derived<int*>* [line 22, column 8]\n n$3=_fun_class_specialization::Base<int*>_Base(n$2:class_specialization::Derived<int*>*) [line 22, column 8]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"Derived#Derived<int*>#class_specialization#{6947111178756325946}.2484a8b63b0d0003a390b6e57428fee2_3" -> "Derived#Derived<int*>#class_specialization#{6947111178756325946}.2484a8b63b0d0003a390b6e57428fee2_2" ;
|
|
|
|
|
"Derived#Derived<int>#class_specialization#{14157761386473130888}.40e79d469e516a33fdff720996ff80ab_1" [label="1: Start class_specialization::Derived<int>_Derived\nFormals: this:class_specialization::Derived<int>*\nLocals: \n DECLARE_LOCALS(&return); [line 17, column 8]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"Derived#Derived<int>#class_specialization#{14157761386473130888}.40e79d469e516a33fdff720996ff80ab_1" -> "Derived#Derived<int>#class_specialization#{14157761386473130888}.40e79d469e516a33fdff720996ff80ab_3" ;
|
|
|
|
|
"Derived#Derived<int>#class_specialization#{14157761386473130888}.40e79d469e516a33fdff720996ff80ab_2" [label="2: Exit class_specialization::Derived<int>_Derived \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
[clang] enforce that `instruction` always returns one SIL expression
Summary:
Previously, the type of `trans_result` contained a list of SIL expressions.
However, most of the time we expect to get exactly one, and getting a different
number is a soft(!) error, usually returning `-1`.
This splits `trans_result` into `control`, which contains the information
needed for temporary computation (hence when we don't necessarily know the
return value yet), and a new version of `trans_result` that includes `control`,
the previous `exps` list but replaced by a single `return` expression instead,
and a couple other values that made sense to move out of `control`. This allows
some flexibility in the frontend compared to enforcing exactly one return
expression always: if they are not known yet we stick to `control` instead (see
eg `compute_controls_to_parent`).
This creates more garbage temporary identifiers, however they do not show up in
the final cfg. Instead, we see that temporary IDs are now often not
consecutive...
The most painful complication is in the treatment of `DeclRefExpr`, which was
actually returning *two* expressions: the method name and the `this` object.
Now the method name is a separate (optional) field in `trans_result`.
Reviewed By: mbouaziz
Differential Revision: D7881088
fbshipit-source-id: 41ad3b5
7 years ago
|
|
|
"Derived#Derived<int>#class_specialization#{14157761386473130888}.40e79d469e516a33fdff720996ff80ab_3" [label="3: Constructor Init \n n$2=*&this:class_specialization::Derived<int>* [line 17, column 8]\n n$3=_fun_class_specialization::Base<int>_Base(n$2:class_specialization::Derived<int>*) [line 17, column 8]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"Derived#Derived<int>#class_specialization#{14157761386473130888}.40e79d469e516a33fdff720996ff80ab_3" -> "Derived#Derived<int>#class_specialization#{14157761386473130888}.40e79d469e516a33fdff720996ff80ab_2" ;
|
|
|
|
|
"foo#Derived<int>#class_specialization#(3691368771332090182).157c4cba925bdfdc131986d2b52af05d_1" [label="1: Start class_specialization::Derived<int>_foo\nFormals: this:class_specialization::Derived<int>* t:int\nLocals: \n DECLARE_LOCALS(&return); [line 18, column 3]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"foo#Derived<int>#class_specialization#(3691368771332090182).157c4cba925bdfdc131986d2b52af05d_1" -> "foo#Derived<int>#class_specialization#(3691368771332090182).157c4cba925bdfdc131986d2b52af05d_3" ;
|
|
|
|
|
"foo#Derived<int>#class_specialization#(3691368771332090182).157c4cba925bdfdc131986d2b52af05d_2" [label="2: Exit class_specialization::Derived<int>_foo \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
[clang] enforce that `instruction` always returns one SIL expression
Summary:
Previously, the type of `trans_result` contained a list of SIL expressions.
However, most of the time we expect to get exactly one, and getting a different
number is a soft(!) error, usually returning `-1`.
This splits `trans_result` into `control`, which contains the information
needed for temporary computation (hence when we don't necessarily know the
return value yet), and a new version of `trans_result` that includes `control`,
the previous `exps` list but replaced by a single `return` expression instead,
and a couple other values that made sense to move out of `control`. This allows
some flexibility in the frontend compared to enforcing exactly one return
expression always: if they are not known yet we stick to `control` instead (see
eg `compute_controls_to_parent`).
This creates more garbage temporary identifiers, however they do not show up in
the final cfg. Instead, we see that temporary IDs are now often not
consecutive...
The most painful complication is in the treatment of `DeclRefExpr`, which was
actually returning *two* expressions: the method name and the `this` object.
Now the method name is a separate (optional) field in `trans_result`.
Reviewed By: mbouaziz
Differential Revision: D7881088
fbshipit-source-id: 41ad3b5
7 years ago
|
|
|
"foo#Derived<int>#class_specialization#(3691368771332090182).157c4cba925bdfdc131986d2b52af05d_3" [label="3: BinaryOperatorStmt: Assign \n n$1=*&this:class_specialization::Derived<int>* [line 18, column 19]\n n$2=*&t:int [line 18, column 29]\n *n$1.x:int=n$2 [line 18, column 19]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"foo#Derived<int>#class_specialization#(3691368771332090182).157c4cba925bdfdc131986d2b52af05d_3" -> "foo#Derived<int>#class_specialization#(3691368771332090182).157c4cba925bdfdc131986d2b52af05d_2" ;
|
|
|
|
|
"foo2#Derived<int*>#class_specialization#(12167928122938213289).9c7a2e679a7d7dcf0338960c56f01bd4_1" [label="1: Start class_specialization::Derived<int*>_foo2\nFormals: this:class_specialization::Derived<int*>* t:int*\nLocals: \n DECLARE_LOCALS(&return); [line 23, column 3]\n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"foo2#Derived<int*>#class_specialization#(12167928122938213289).9c7a2e679a7d7dcf0338960c56f01bd4_1" -> "foo2#Derived<int*>#class_specialization#(12167928122938213289).9c7a2e679a7d7dcf0338960c56f01bd4_3" ;
|
|
|
|
|
"foo2#Derived<int*>#class_specialization#(12167928122938213289).9c7a2e679a7d7dcf0338960c56f01bd4_2" [label="2: Exit class_specialization::Derived<int*>_foo2 \n " color=yellow style=filled]
|
|
|
|
|
|
|
|
|
|
|
[clang] enforce that `instruction` always returns one SIL expression
Summary:
Previously, the type of `trans_result` contained a list of SIL expressions.
However, most of the time we expect to get exactly one, and getting a different
number is a soft(!) error, usually returning `-1`.
This splits `trans_result` into `control`, which contains the information
needed for temporary computation (hence when we don't necessarily know the
return value yet), and a new version of `trans_result` that includes `control`,
the previous `exps` list but replaced by a single `return` expression instead,
and a couple other values that made sense to move out of `control`. This allows
some flexibility in the frontend compared to enforcing exactly one return
expression always: if they are not known yet we stick to `control` instead (see
eg `compute_controls_to_parent`).
This creates more garbage temporary identifiers, however they do not show up in
the final cfg. Instead, we see that temporary IDs are now often not
consecutive...
The most painful complication is in the treatment of `DeclRefExpr`, which was
actually returning *two* expressions: the method name and the `this` object.
Now the method name is a separate (optional) field in `trans_result`.
Reviewed By: mbouaziz
Differential Revision: D7881088
fbshipit-source-id: 41ad3b5
7 years ago
|
|
|
"foo2#Derived<int*>#class_specialization#(12167928122938213289).9c7a2e679a7d7dcf0338960c56f01bd4_3" [label="3: BinaryOperatorStmt: Assign \n n$1=*&this:class_specialization::Derived<int*>* [line 23, column 21]\n n$2=*&t:int* [line 23, column 31]\n *n$1.x:int*=n$2 [line 23, column 21]\n " shape="box"]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"foo2#Derived<int*>#class_specialization#(12167928122938213289).9c7a2e679a7d7dcf0338960c56f01bd4_3" -> "foo2#Derived<int*>#class_specialization#(12167928122938213289).9c7a2e679a7d7dcf0338960c56f01bd4_2" ;
|
|
|
|
|
}
|
