Some languages store a variable in a location whose indirection level is
only known at runtime. Swift, for example, emits resilient globals into
a fixed-size buffer; a value that doesn't fit is boxed on the heap and
the buffer holds a pointer to the box. Whether the value fits depends on
the runtime layout of a type, so the compiler can't encode it in the
DWARF location expression.
This patch adds a LanguageRuntime hook that ValueObjectVariable calls
after evaluating a variable's location, so the runtime can adjust it.
The default implementation does nothing.
Assisted-by: Claude
This API will be called, for example, by DIL to determine whether
expressions with assignments can be evaluated. In these cases it will be
beneficial to also return a reason for the denial to the user.
This patch also updates the SBAPI variant of this
method. Unfortunately `bool SBValue::CanSetValue()` is already in the
stable/23.x branch, so I am adding a new method `SBError
SBValue::CanSet()`. The "Value" in the name is redundant, so this should
be a nice API cleanup.
IDEs may offer functionality to set a variable to a specific value.
There are many situations where this isn't actually possible, for
example, if the variable's value is a constant or the result of a
complex DWARF expression. Instead of offering to change a value only to
have it fail with an error, this API lets the IDE query whether setting
a value is generally feasible so it can hide the action where it isn't
applicable.
rdar://142358140
Assisted-by: claude
This makes the constructions of string errors more concise and more
consistent, mainly by removing the `inconvertibleErrorCode()`.
Additional changes replace `createStringError(formatv(...), ...)` with
`createStringErrorV(...)`.
Assisted-by: Claude
This patch pushes the error handling boundary for the GetBitSize()
methods from Runtime into the Type and CompilerType APIs. This makes it
easier to diagnose problems thanks to more meaningful error messages
being available. GetBitSize() is often the first thing LLDB asks about a
type, so this method is particularly important for a better user
experience.
rdar://145667239
Many calls to Function::GetAddressRange() were not interested in the
range itself. Instead they wanted to find the address of the function
(its entry point) or the base address for relocation of function-scoped
entities (technically, the two don't need to be the same, but there's
isn't good reason for them not to be). This PR creates a separate
function for retrieving this, and changes the existing
(non-controversial) uses to call that instead.
ValueObject is part of lldbCore for historical reasons, but conceptually
it deserves to be its own library. This does introduce a (link-time) circular
dependency between lldbCore and lldbValueObject, which is unfortunate
but probably unavoidable because so many things in LLDB rely on
ValueObject. We already have cycles and these libraries are never built
as dylibs so while this doesn't improve the situation, it also doesn't
make things worse.
The header includes were updated with the following command:
```
find . -type f -exec sed -i.bak "s%include \"lldb/Core/ValueObject%include \"lldb/ValueObject/ValueObject%" '{}' \;
```
Adrian Prantl