1

After changing a boolean to false in lldb, it's still evaluating to true. Here's a simplified version.

=> is a breakpoint

func getCount(actionWasSuccessful successful: Bool) -> Int {
=>  var count = 0

    // (lldb) po successful (returns true)
    // (lldb) exp successful = false
    // (lldb) po successful (returns false)

    if successful {
=>      count += 1 // breakpoint stops here
    } else {
=>      count = 0 // breakpoint should stop here
    }
    return count
}

let count = getCount(successful: true)
print(count) // returns 1
h.and.h
  • 690
  • 1
  • 8
  • 26
  • Possibly Related: https://stackoverflow.com/questions/31367005/why-is-xcodes-variables-views-edit-value-not-changing-the-variable-value – Ahmad F Apr 23 '19 at 20:01
  • You may need sleep; you are passing true to this:`let count = getCount(successful: true)` What does it return if you write: `let count = getCount(successful: false)`? – ThomasHaz Apr 24 '19 at 19:23
  • @ThomasHaz, If it's passed ```false```, it returns 0, as expected. But if I change ```successful``` to true where I'm changing it to ```false``` in my question, it is also incorrect. – h.and.h Apr 24 '19 at 21:34

1 Answers1

3

Swift plays tricks with debug information. For instance it keeps "shadow" copies of variables which it reports to the debugger to work around the fact that swift is aggressive about deleting variables as soon as it can reason that they are no longer accessible. If it didn't make another copy that exists throughout the block in which the variable is defined, many of your local variables would become unavailable too early as you stepped through the function. The shadow copies are kept up to date, but there's no way for lldb to push the change from the shadow to the actual variable at present.

The shadow copy solves one fairly serious debugging problem at the expense of making it harder to change variable values through the debugger. From what I've heard a more principled solution to the problem is not trivial.

Do file a bug about this with bugs.swift.org. That will help the compiler folks prioritize this properly.

Jim Ingham
  • 25,260
  • 2
  • 55
  • 63