summaryrefslogtreecommitdiffstats
path: root/lldb/packages/Python/lldbsuite/test/expression_command/call-function/TestCallStopAndContinue.py
diff options
context:
space:
mode:
authorRafael Espindola <rafael.espindola@gmail.com>2015-12-01 17:17:04 +0000
committerRafael Espindola <rafael.espindola@gmail.com>2015-12-01 17:17:04 +0000
commit6e8ab928d51e120700169275c2c0707abd796a84 (patch)
treece18e7dec6e22d9a9f717dbb0123e8f299d92d57 /lldb/packages/Python/lldbsuite/test/expression_command/call-function/TestCallStopAndContinue.py
parenta9918e897bbbedcd4c94ccf024223a898cdbfc95 (diff)
downloadbcm5719-llvm-6e8ab928d51e120700169275c2c0707abd796a84.tar.gz
bcm5719-llvm-6e8ab928d51e120700169275c2c0707abd796a84.zip
Make appending var linking less of a special case.
It has to be a bit special because: * materializeInitFor is not really supposed to call replaceAllUsesWith. The caller has a plain variable with Dst and expects just the initializer to be set, not for it to be removed. * Calling mutateType as we used to do before gets some type inconsistency which breaks the bitcode writer. * If linkAppendingVarProto create a dest decl with the correct type to avoid the above problems, it needs to put the original dst init in some side table for materializeInitFor to use. In the end the simplest solution seems to be to just have linkAppendingVarProto do all the work and set ValueMap[SrcGV to avoid recursion. llvm-svn: 254424
Diffstat (limited to 'lldb/packages/Python/lldbsuite/test/expression_command/call-function/TestCallStopAndContinue.py')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud