[llvm-branch-commits] [lldb] [lldb] Add extended variable support to Get*VariableList. (PR #181501)
Med Ismail Bennani via llvm-branch-commits
llvm-branch-commits at lists.llvm.org
Wed Apr 15 22:22:52 PDT 2026
medismailben wrote:
> > 1. not to bike shed about names but I'm not a big fan of "extended variables" because it sounds like we're augmenting an existing variable but actually in this case, you're making one from scratch. I think "synthetic variables" would make more sense here, and we're already using it for SyntheticFrames and SyntheticFrameProviders.
>
> Fair enough - I was largely going off Jim's naming for this so I just used "extended". Happy to rename, assuming it doesn't clash with anything :)
>
Sure, let's see if @jimingham has any objection but I doubt it.
> > 2. Until then we didn't have to do any composition on the ValueType enum but that's not true anymore. Ideally I'd turn the `ValueType` enum into a struct and add some helper functions to get the value type without the extended mask, but that would be quite an intrusive change. We could still make a standalone function (like we do for `StateIsRunningState` for the `StateType` enum) to wrap and unwrap the ValueType from the extended mask.
>
> Yes I agree - I was actually exploring turning it into a bit enum, but yeah that would've been a HUGE change. I thought I added a function to wrap/unwrap but I guess not. Do you want a new header for that or should I just drop it into lldb-enumerations.h? It should be a one-liner.
I don't think `lldb-enumerations.h` has any function in it so I suggest following the same approach as StateType and adding a `ValueType.h` under `lldb/Utility` that has the helper functions. FWIW I think they should be inlined.
https://github.com/llvm/llvm-project/pull/181501
More information about the llvm-branch-commits
mailing list