Add a blog post entry on what's new in Swift debugging in 5.9 #368
Conversation
adrian-prantl
requested review from
cthielen,
TimTr,
tkremenek,
tomerd,
0xTim,
alexandersandberg,
daveverwer,
dempseyatgithub,
parispittman,
kaishin,
mschinis and
shahmishal
as code owners
adrian-prantl
force-pushed
the
swift-debugging-5.9
branch
from
3bb5d05 to
ec8f926
Compare
|
@swift-ci test |
Co-authored-by: Alexander Sandberg <[email protected]>
|
@swift-ci test |
| layout: post | ||
| published: true | ||
| date: 2023-08-25 12:34:56 | ||
| title: What's new in Swift debugging on the 5.9 branch? |
There was a problem hiding this comment.
Smart quote: What’s
The title says ‘on the 5.9 branch’ but by now everything in the 5.9 branch has been merged and released.
A different title would be more accurate. Possibly:
“What’s new in debugging in Swift 5.9?”
Or, since the changes include LLDB, maybe the intent was to indicate it is more than a Swift compiler change?
If so, maybe use “5.9 toolchain” instead of “5.9 branch”?
“What’s new in Swift debugging in the 5.9 toolchain”
Another approach might be to emphasize that these are improvements and not just new things:
“Debugging improvements in the Swift 5.9 toolchain”
or more concise:
“Debugging Improvements in Swift 5.9"
There was a problem hiding this comment.
Agreed with James. "Debugging Improvements in Swift 5.9" sounds good to me.
| layout: post | ||
| published: true | ||
| date: 2023-08-25 12:34:56 | ||
| title: What's new in Swift debugging on the 5.9 branch? |
There was a problem hiding this comment.
Agreed with James. "Debugging Improvements in Swift 5.9" sounds good to me.
|
|
||
| In fact, the Swift language's scoping rules allow some astonishing things to be done with variable bindings: | ||
|
|
||
| ```swift |
There was a problem hiding this comment.
This example is a little inscrutable. Again, it feels like it would be more impactful to show what was before and after. How was the scope information lacking in information before?
| 42 | ||
| ``` | ||
|
|
||
| With the debug information produced by previous versions of the Swift compiler, the debugger might have displayed uninitialized memory as the contents of `a` at the call site of `getInt()`. In Swift 5.9 the variable `a` only becomes visible after it has been initialized. |
There was a problem hiding this comment.
This paragraph should be brought up to the start of this section. Otherwise, you're sort of showing something and then explaining what was shown. Better to state the change, then demonstrate it.
|
|
||
| With the debug information produced by previous versions of the Swift compiler, the debugger might have displayed uninitialized memory as the contents of `a` at the call site of `getInt()`. In Swift 5.9 the variable `a` only becomes visible after it has been initialized. | ||
|
|
||
| For more details, see the [pull request](https://github.com/apple/swift/pull/64941) that introduced this change. |
There was a problem hiding this comment.
Is there better documentation than the PR?
|
|
||
| LLDB provides the shorthand `p` command alias to inspect variables and `po` to call the debugDescription property of objects. Originally, these were aliases for the rather heavyweight `expression` and `expression -O` commands. In Swift 5.9, the `p` and `po` command aliases have been redefined to the new `dwim-print` command. The `dwim-print` command prints values using the most user-friendly implementation. "DWIM" is an acronym for "Do What I Mean". Specifically, when printing variables, `dwim-print` will use the same implementation as `frame variable` or `v` instead of the more expensive expression evaluator. | ||
|
|
||
| "In addition to being faster, using `p` no longer creates persistent result variables like `$R0`, which are often unused in debugging sessions. Persistent result variables not only incur overhead but also retain any objects they contain, which can be an unexpected side effect for the program execution. Users who want persistent results on occasion, can use `expression` (or a unique prefix such as `expr`) directly instead of `p`. To enable persistent results every time, the `p` alias can be redefined in the `~/.lldbinit` file: |
There was a problem hiding this comment.
Looks like there's an extra double quote here.
| command alias p dwim-print --persistent-result on -- | ||
| ``` | ||
|
|
||
| The `dwim-print` command also gives `po` new functionality. The `po` command can now print Swift objects by their *address*. When running `po <object-address>`, LLDB's embedded Swift compiler will automatically evaluate the expression `unsafeBitCast(<object-address>, to: AnyObject.self)` under the hood to produce the expected result. |
There was a problem hiding this comment.
"print Swift objects by their address" sounds like the basic functionality of telling me the address of a variable. Is a better way to saying this, "identifying Swift objects at a given address"?
|
|
||
| Running `po T.self`, when stopped in `use`, will print `Int` when coming in through the first call, and `String` in the second. In addition to displaying the concrete type of the generic, you can use this to set conditional that look for concrete types. For example, adding the following expression as the condition to a breakpoint inside `use` will only stop when the variable `t` is a `String`: `T.self == String.self`. (Note that this last example only works on nightly builds of the Swift 5.9 toolchain.) | ||
|
|
||
| More details about the implementation of this feature can be found in the [LLDB PR](https://github.com/apple/llvm-project/pull/5715) introducing it. |
There was a problem hiding this comment.
Let's do "pull request" instead of PR.
|
|
||
| Running `po T.self`, when stopped in `use`, will print `Int` when coming in through the first call, and `String` in the second. In addition to displaying the concrete type of the generic, you can use this to set conditional that look for concrete types. For example, adding the following expression as the condition to a breakpoint inside `use` will only stop when the variable `t` is a `String`: `T.self == String.self`. (Note that this last example only works on nightly builds of the Swift 5.9 toolchain.) | ||
|
|
||
| More details about the implementation of this feature can be found in the [LLDB PR](https://github.com/apple/llvm-project/pull/5715) introducing it. |
There was a problem hiding this comment.
| More details about the implementation of this feature can be found in the [LLDB PR](https://github.com/apple/llvm-project/pull/5715) introducing it. | |
| More details about the implementation of this feature can be found in the [LLDB pull request](https://github.com/apple/llvm-project/pull/5715) introducing it. |
Moved LLVM review links
|
|
||
| LLDB provides the shorthand `p` command alias to inspect variables and `po` to call the debugDescription property of objects. Originally, these were aliases for the rather heavyweight `expression` and `expression -O` commands. In Swift 5.9, the `p` and `po` command aliases have been redefined to the new `dwim-print` [command](https://reviews.llvm.org/D138315 "LLVM review"). The `dwim-print` command prints values using the most user-friendly implementation. "DWIM" is an acronym for "Do What I Mean". Specifically, when printing variables, `dwim-print` will use the same implementation as `frame variable` or `v` instead of the more expensive expression evaluator. | ||
|
|
||
| In addition to being faster, using `p` no longer creates [persistent result variables](https://reviews.llvm.org/D145609 "LLVM review") like `$R0`, which are often unused in debugging sessions. Persistent result variables not only incur overhead but also retain any objects they contain, which can be an unexpected side effect for the program execution. |
There was a problem hiding this comment.
the program execution -> program execution
| use("Hello!”) | ||
| ``` | ||
|
|
||
| Running `po T.self`, when stopped in `use`, will print `Int` when coming in through the first call, and `String` in the second. In addition to displaying the concrete type of the generic, you can use this to set conditional that look for concrete types. For example, adding the following expression as the condition to a breakpoint inside `use` will only stop when the variable `t` is a `String`: `T.self == String.self`. (Note that this last example only works on nightly builds of the Swift 5.9 toolchain.) |
There was a problem hiding this comment.
set conditional -> set conditions
|
@swift-ci test |
Add a blog post entry on what's new in Swift debugging in the 5.9 branch.
Motivation:
On the Swift 5.9 branch we introduced a couple of new features to LLDB and the Swift compiler to improve the debugging experience. In this post we are highlighting three changes that we expect to have the most noticeable impact on Swift debugging workflows.
Modifications:
Added
_posts/2023-08-25-whats-new-swift-debugging-5.9.mdAmended
_data/authors.ymlResult:
A new blog post!