Initial work on improving scopes such that symbols are correctly removed#367
Initial work on improving scopes such that symbols are correctly removed#367aytey merged 3 commits intostp:masterfrom
Conversation
Signed-off-by: Andrew V. Jones <[email protected]>
…ected symbols Signed-off-by: Andrew V. Jones <[email protected]>
|
+1 looks good to me but @TrevorHansen may need to check as he is more familiar with this part of the code :) |
lib/Interface/cpp_interface.cpp
Outdated
| for (vector<std::string>::const_iterator scoped_function_name = | ||
| getFunctions().begin(); | ||
| scoped_function_name != getFunctions().end(); ++scoped_function_name) | ||
| { |
There was a problem hiding this comment.
Feel free to use modern style if you'd like:
for (const auto& scoped_function_name : getFunctions())
lib/Interface/cpp_interface.cpp
Outdated
| scoped_function_name != getFunctions().end(); ++scoped_function_name) | ||
| { | ||
| // Find this function in the global context | ||
| std::unordered_map<std::string, Function>::iterator function_to_erase = |
There was a problem hiding this comment.
You could make make this:
std::unordered_map<const std::string, Function>::const_iterator function_to_erase =
or
const auto function_to_erase =
if you wanted to.
TrevorHansen
left a comment
There was a problem hiding this comment.
Thanks for fixing up my mistakes!~
|
@TrevorHansen for:
Do you have a preference? Basically, I'm not a huge fan of For example, if I use an If you don't use Maybe the compromise here is that iterators should use |
|
My usual approach is: when in doubt, steal from the LLVM Coding Standards or whichever major project you like. Try to match nearby code so future readers don't need to switch between styles. They have a stance on |
|
Shall we set up a |
|
I don't mean to come across like I have strong feelings about ```auto''', or coding guidelines. I was looking for something to comment on mostly so that it was obvious that I took @andrewvaughanj 's contribution seriously enough to read through it. If it'd make it easier for people to contribute to STP, then yes, I'm very keen on coding guidelines. Otherwise, I'm happy to let people exercise their judgement - we get so few patches through it's hard for me to imagine it all becoming chaos. Thanks again for fixing up the function stuff! |
Signed-off-by: Andrew V. Jones <[email protected]>
|
Haven't followed the discussion closely: @andrewvaughanj if this is ready to go, please merge. |
I think this is good -- @TrevorHansen was happy + Travis is green. Will merge! |
Issue
As identified in #365, the creation of functions can allow for symbols to escape having their reference count decreased to zero, and therefore their lifetimes are longer than we would expect.
Example
After popping
x!2andx!3, it should not be possible to refer tox!2, but STP allows this.Solution
This PR reworks the symbol/function scopes inside of STP such that popping a frame also removes the functions declared in that scope.
Discussion
I opted to keep a pointer to the "global" function context and then remove the popped functions during destruction of a frame.
An alternative would be change
Cpp_interface::applyFunctionto search through all of the frames (starting from the deepest) to find which to apply.I have initially opted to tweaking how the scopes were stored, as this seemed like the less-invasive approach. Now that we have a
SolverFrameclass, we can improveCpp_interface::applyFunctionin the future to also use a "frame" of functions (rather than a global map).