jingham added a comment. In Swift you have to ask the runtime for most of the layout details of objects so getting a const result object, stepping, then asking it to reevaluate itself would lead to passing the runtime incorrect data and potentially undoing a correct type decision that you had made when you fetched the result on the first stop. That's what it sounded like from Davide's description, but I haven't looked at it more deeply yet.
All the ValueObjects have a ModID, so you for const objects you should always check that before updating. I think the problem is this just never happened before because the code was not in the ValueObjectConst inheritance path. By hoisting that code into ValueObject, now it was, but it was not correct to do that without consulting the modID. Note that for cases like this we check the last user stop, not the actual last stop. We really can't avoid running expressions to get dynamic types and some other jobs, so we really want to consider had run expressions as not changing the essential state of the program. This hasn't caused problems in practice, and if it were to become a problem we could classify expressions as state changing or not state changing, and move the user stop ID forward for the former as well... Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D69273/new/ https://reviews.llvm.org/D69273 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
