While looking at the '[raw]' value of a std::vector I noticed we didn't
handle the anonymous inner struct very well. The 'evaluateName' was
incorrect (e.g. the evaluateName would return `<var>.` for the anonymous
struct).
This improves support for variables with anonymous fields and anonymous
types.
* Changed the name of anonymous fields from `<null>` to `(anonymous)`,
which matches other tooling like clangd's representation and how types
are presented if the field is not defined.
* Adjusts variables to not return an 'evaluateName' for anonymous
fields.
* Adjusted '[raw]' values to be marked as 'internal' which deemphasizes
them in the UI.
While working in this area, I also consolidated some helpers that are
only used within Variables.cpp.
Before my changes:
<img width="513" height="460" alt="before"
src="https://github.com/user-attachments/assets/3da0aada-8ba3-415d-bbec-56b41a9b9415"
/>
After my changes:
<img width="414" height="467" alt="after"
src="https://github.com/user-attachments/assets/66a47108-ee44-4e01-8eab-e89edb348fde"
/>
This paths allows expressions in `setVariable` request. It is small
extension of original semantics from DAP specification. DAP has
`setExpression` request to this purpose, but it is too general. So I
prefer to keep this simple solution.
Adjusting `VariableReferenceStorage` to only need to track permanent vs
temporary storage by making `VariableStore` the common base class.
Moved the subclasses of `VariableStore` into the Variables.cpp file,
since they're no long referenced externally.
Expanding on the tests by adding an updated core dump with variables in
the argument scope we can use to validate variable storage.
This commit refactors the Variables class into a
VariableReferenceStorage with variableReferences of different
ReferenceKinds.
The variablesReference is now a uint32_t.
The most significant byte (bits 24 - 31) holds the reference kind and
the remaining 3 bytes (bits 0 -23) holds the actual reference.
We have (at the moment) 3 reference kinds.
Temporary => 0b0000 => 0x00
Permanent => 0b0001 => 0x01
Scope => 0b0010 => 0x03
The actual variablesReference can be used to get a `VariableStore`.
VariableStore holds variables in a group.
It has two implementations:
- ScopeStore: Holds variables within frame scopes (locals, globals,
registers). This is lazy-loaded and only fetched when variable(s) in the
scope is requested.
- ExpandableValueStore: Holds SBValue and fetches it's variable children
when requested.
ReferenceKindPool:
The variablesReference created starts from 1 with the mask of the
Reference kind applied.
It holds vector of VariableStore of one Referencekind,
This allows constant lookup of a reference
Example:
```md
| maskedVariablesReference | Mask | variablesReference | RefrenceKind | VariableStore |
|--------------------------|------|--------------------|--------------|---------------|
| 20 -> 0x00000014 | 0x00 | 20 -> 0x00000014 | temporary | ValueStore |
| 268435476 -> 0x01000014 | 0x01 | 20 -> 0x00000014 | permanent | ValueStore |
| 536870932 -> 0x01000014 | 0x02 | 20 -> 0x00000014 | scope | ScopeStore |
```
This patch fixes the problem, when after a `setVariable` request
pointers and references to the variable are not updated. VSCode doesn't
send a `variables` request after a `setVariable` request, so we should
trigger it explicitly via`invalidated` event .Also, updated
`writeMemory` request in similar way.
This updates all the existing memory reference fields to use
`lldb::addr_t` directly.
A few places were using `std::string` and decoding the value in the
request handler and other places had unique ways of parsing addresses.
This unifies all of these references with the `DecodeMemoryReference`
helper in JSONUtils.h.
Additionally, for the types I updated, I tried to simplify the POD types
some and moved default values out of RequestHandlers and into the
protocol POD types.
```cpp
// The "id" is the unique integer ID that is unique within the enclosing
// variablesReference. It is optionally added to any "interface
Variable"
// objects to uniquely identify a variable within an enclosing
// variablesReference. It helps to disambiguate between two variables
that
// have the same name within the same scope since the "setVariables"
request
// only specifies the variable reference of the enclosing
scope/variable, and
// the name of the variable. We could have two shadowed variables with
the
// same name in "Locals" or "Globals". In our case the "id" absolute
index
// of the variable within the dap.variables list.
const auto id_value =
GetInteger<uint64_t>(arguments, "id").value_or(UINT64_MAX);
if (id_value != UINT64_MAX) {
```
I dropped this part because. variables that have the same name has a ` @path` suffix on both of them.
and the setVariableArguments does not have a field called `id`.
This moves all the common settings of the launch and attach operations
into the `lldb_dap::protocol::Configuration`. These common settings
can be in both `launch` and `attach` requests and allows us to isolate
the DAP configuration operations into a single common location.
This is split out from #133624.
Replace Get{Signed,Unsigned} with GetInteger<T> and return std::optional
so you can distinguish between the value not being present and it being
explicitly set to the previous fail_value. All existing uses are
replaced by calling value_or(fail_value).
Continuation of #129818
