[Lldb-commits] [lldb] [lldb] Start using formatv() in RegisterContextUnwind (NFCI) (PR #191576)

[Sergei Barannikov via lldb-commits]

s-barannikov wrote:

> > I didn't replace all function calls with macros because there are too many of them for one PR. This only replaces calls whose format string contains no specifiers or only '%s' specifiers.
> 
> That's sensible but can I just confirm that the motivation for this work is to tackle uses like:
> 
> ```
>     UnwindLogMsg("with pc value of 0x%" PRIx64 ", symbol name is '%s'",
>                  current_pc, GetSymbolOrFunctionName(m_sym_ctx).AsCString(""));
> ```
> 
> Where we don't have to predict the format specifier, and we can pass in StringRefs and other things directly.

Basically, yes.
It also allows us to remove C-style casts, so something like this
```C++
  UnwindLogMsg("initialized frame current pc is 0x%" PRIx64 " cfa is 0x%" PRIx64
               " afa is 0x%" PRIx64 " using %s UnwindPlan",
               (uint64_t)m_current_pc.GetLoadAddress(exe_ctx.GetTargetPtr()),
               (uint64_t)m_cfa,
               (uint64_t)m_afa,
               m_full_unwind_plan_sp->GetSourceName().GetCString());
```
becomes
```C++
  UNWIND_LOG(log,
             "initialized frame current pc is {0:x} cfa is {1:x} afa is {2:x} "
             "using {3} UnwindPlan",
             m_current_pc.GetLoadAddress(exe_ctx.GetTargetPtr()), m_cfa, m_afa,
             m_full_unwind_plan_sp->GetSourceName());
```
I guess they were used in case the underlying type changes (otherwise they are just redundant), but with `formatv()` we don't have to worry about that.

IOW this is just a cleanup, but to be completely honest it also pursues a selfish goal of reducing the number of downstream changes (where I have to use more functions like the mentioned AsCString to make the code compilable). I realize this is a weak argument, feel free to ignore it.


https://github.com/llvm/llvm-project/pull/191576