Files
Dave Lee 637f9d7122 [lldb] Fix compile Python f-strings to improved @fmt (#232997)
Updates the `@fmt` selector, by adding support for Python f-strings to
the Python to bytecode compiler, and updating the evaluation of `@fmt`
by improved interfacing with `llvm::formatv`.

Changes to `@fmt`:

* Consume the arguments, leaving only the resulting string on the stack.
Previously, the arguments were left on the stack, unlike what the docs
describe and what the interpreter does.
* In version 2 formatters, replacements are automatically indexed.
Explicit indexes,such as `{0}`, are an error. This makes the stack
effect of `@fmt` clear from the format string: the number of arguments
is the number of replacements, and each argument is used once, in stack
order. Arguments can be reordered or reused with the stack operations.
* In version 2 formatters, layouts and options (`{,8}`, `{:x}`) are
accepted, but are currently ignored. They are treated as best effort
hints, so that support for them can be added later without changing the
ABI.
* In version 2 formatters, the format string is checked by LLDB before
it reaches `formatv`, which is given only literal text, escaped braces,
and `{}`. Format strings come from the binary being debugged, and
`formatv` asserts on malformed input. Layouts with a very large width,
such as `{,4000000000}`, would also build a very large string, even in
release builds.

Version 1 formatters are unchanged, except for consuming their
arguments.

Changes to formatter_bytecode.py:

* f-strings are compiled to `@fmt`. Conversions (`{x!r}`) and format
specs (`{x:>8}`) are not supported, and are a compile error.
* String literals, including f-strings, escape quotes and backslashes
when emitting assembly.
* The interpreter's `@fmt` matches the C++ interpreter. It now passes
arguments in stack order, supports `{}`, and follows the `formatv` rules
for braces (`{{` is a literal `{`, and a lone `}` is a literal).

Assisted-by: claude
2026-10-20 22:47:20 +00:00
..