labath added a comment. In D69273#1732582 <https://reviews.llvm.org/D69273#1732582>, @jingham wrote:
> 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... Hmm.. that's interesting. But what is the thing that's causing the layout to be "reevaluated"? Is it the `GetCompilerType()` call on line 141? Should we maybe just have ValueObjectConstResult override `GetCompilerType` so that it "freeze-dries" the type too ? From your description, it sounds like that's exactly the semantics we want here... 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
