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%" '{}' \;
```
This reverts commit 927def49728371d746476e79a6570cd93a4d335c.
I've refactored the tests so that we're explicit about whether the
enum is signed or not. Which means we use the proper types
throughout.
Enums like this one are treated as bitfield like enums: enum FlagsLike
{B=2, C=4};
lldb recognises them as collections of flags, so you can have "B | C".
If there's any values not covered that's printed as hex "B | C | 0x1".
What happened if the value was 0 was we would not match any of the
enumerators, then the remainder check requires that the remainder is
non-zero. So lldb would print nothing at all.
Which I assume is a bug because knowing that no flags are set is useful,
just as much as knowing that some unkown bit was set to make it
non-zero.
Fixes#97514
Given this example:
```
enum E {};
int main()
{
E x = E(0);
E y = E(1);
E z = E(2);
return 0;
}
```
lldb used to print nothing for `x`, but `0x1` for `y` and `0x2` for `z`.
At first this seemed like the 0 case needed fixing but the real issue
here is that en enum with no enumerators was being detected as a
"bitfield like enum".
Which is an enum where all enumerators are a single bit value, or the
sum of previous single bit values.
For these we do not print anything for a value of 0, as we assume it
must be the remainder after we've printed the other bits that were set
(I think this is also unfortunate, but I'm not addressing that here).
Clearly an enum with no enumerators cannot be being used as a bitfield,
so check that up front and print it as if it's a normal enum where we
didn't match any of the enumerators. This means you now get:
```
(lldb) p x
(E) 0
(lldb) p y
(E) 1
(lldb) p z
(E) 2
```
Which is a change to decimal from hex, but I think it's overall more
consistent. Printing hex here was never a concious decision.
This change by itself has no measurable effect on the LLDB
testsuite. I'm making it in preparation for threading through more
errors in the Swift language plugin.
DumpValueObjectOptions can only be created and modified from C++. This
means it's currently only testable from Python by calling some command
that happens to use one, and even so, you can't pick which options get
chosen.
So we have decent coverage for the major options that way, but I want to
add more niche options that will be harder to test from Python (register
field options).
So this change adds some "unit tests", though it's stretching the
definition to the point it's more "test written in C++". So we can test
future options in isolation.
Since I want to add options specific to enums, that's all it covers.
There is a test class that sets up the type system so it will be easy to
test other types in future (e.g. structs, which register fields also
use).
