llvm-project.git - Unnamed repository; edit this file 'description' to name the repository.

Age	Commit message (Collapse)	Author
2025-05-20	[lldb] Retcon SBValue::GetChildAtIndex(synthetic=true) (#140065)	Pavel Labath
	The motivation here is being (un)able to treat pointer values as an array consistently. This works for pointers to simple/scalar values, but for aggregates, we get a very surprising result: - GetChildAtIndex(x, ??, true) returns the `x` child of the zeroth array member (the one you get by dereferencing the pointer/array) for all `x` which are smaller than the number of children of that value. - for other values of `x`, we get `v[x]`, where `v` is treated like a (C) pointer This patch reimagines this interface so that the value of `true` always treats (pointer and array) values as pointers. For `false`, we always dereference pointers, while in the case of arrays, we only return the values as far as the array bounds will allow. This has the potential to break existing code, but I have a suspicion that code was already broken to begin with, which is why I think this would be better than introducing a new API and keeping the old (and surprising) behavior. If our own test coverage is any indication, breakage should be minimal.
2023-12-19	[lldb] Fix TestSBValueSynthetic on windows (#75908)	Pavel Labath
	We don't have a std::vector formatter on windows, so use a custom formatter in this test to avoid relying on std::vector.
2023-12-18	[lldb] Fix a quirk in SBValue::GetDescription (#75793)	Pavel Labath
	The function was using the default version of ValueObject::Dump, which has a default of using the synthetic-ness of the top-level value for determining whether to print _all_ values as synthetic. This resulted in some unusual behavior, where e.g. a std::vector is stringified as synthetic if its dumped as the top level object, but in its raw form if it is a member of a struct without a pretty printer. The SBValue class already has properties which determine whether one should be looking at the synthetic view of the object (and also whether to use dynamic types), so it seems more natural to use that.