[lldb] Summary string parsing error for strings with bitfield syntax

[wardw]

On update from lldb 16 to 18 I observe that summary strings that include the documented bitfield syntax no longer parse, reporting "error: summary string parsing error" instead.

Taking the example directly from the documentation, and a vanilla instance of lldb

> lldb --no-lldbinit
>> expr 1234.f           # Prints OK
(float) $0 = 1234      
>> type summary add --summary-string "Sign: ${var[31]%B} Exponent: ${var[30-23]%x} Mantissa: ${var[0-22]%u}" float
>> expr 1234.f
(float) $1 = 1234 error: summary string parsing error

This was working fine with lldb 16. The above was tested with lldb version 18.1.6 packaged for Fedora 40.

[llvmbot]

@llvm/issue-subscribers-lldb

Author: None (wardw)

On update from lldb 16 to 18 I observe that summary strings that include the documented bitfield syntax no longer parse, reporting _"error: summary string parsing error"_ instead. Taking the example directly from the [documentation](https://lldb.llvm.org/use/variable.html#bitfields-and-array-syntax), and a vanilla instance of `lldb` > lldb --no-lldbinit >> expr 1234.f # Prints OK (float) $0 = 1234 >> type summary add --summary-string "Sign: ${var[31]%B} Exponent: ${var[30-23]%x} Mantissa: ${var[0-22]%u}" float >> expr 1234.f (float) $1 = 1234 error: summary string parsing error This was working fine with lldb 16. The above was tested with lldb version 18.1.6 packaged for Fedora 40.

[Michael137]

Hmm this works fine for me on top-of-tree as of commit b0f20f214ab43c800130e0d249e8ee2459b906ea on macOS:

$ ./bin/lldb
(lldb) expr 1234.f                                                                                     
(float) $0 = 1234
(lldb) type summary add --summary-string "Sign: ${var[31]%B} Exponent: ${var[30-23]%x} Mantissa: ${var[0-22]%u}" float
(lldb) expr 1234.f                                                                                     
(float) $1 = 1234 Sign: false Exponent: 0x00000089 Mantissa: 1720320

[wardw]

Well that's good. Afraid I'm not really knowledgeable enough with LLVM to know what could impact this and whether for example this could be a downstream/packaging thing, or simply something I've messed up (always and ever-possible, but I can't immediately think why?).

In some sense it would be surprising if something as visible as this were affecting all users without being addressed already. But i thought it was interesting on account of the change occurring more or less exactly at the time I upgraded LLDB from 16 -> 18 (going fedora 38 -> 40) as to at least be noteworthy - perhaps that's useful information to someone? That said, unless someone else can verify, feel free to close.

[Michael137]

In some sense it would be surprising if something as visible as this were affecting all users without being addressed already. But i thought it was interesting on account of the change occurring more or less exactly at the time I upgraded LLDB from 16 -> 18 (going fedora 38 -> 40) as to at least be noteworthy - perhaps that's useful information to someone? That said, unless someone else can verify, feel free to close.

Yea it could be something that temporarily broke in the 18 release but the fix didn't make it? Thanks for reporting this either way. I'll try to see what happens on my Ubuntu machine