jimingham wrote:
> > So maybe a better way to do this feature is to add {Get,Set}TryDILFirst to
> > SBExpressionOptions. Then the versions of CreateValueFromExpression that
> > DON'T take an SBExpressionOption would read the Target setting and use that
> > to set the SBExpressionOption value, but there would still be a way to
> > control this behavior w/o having to change a global setting by using the
> > options object explicitly.
>
> @jimingham Done. Still curious, could
> `SyntheticChildrenFrontEnd::CreateChildValueObjectFromExpression` benefit
> from using DIL in the same way?
CreateChildValueObjectFromExpression doesn't work correctly yet. It still
creates root value objects that it then adds to the ValueObjects managed by the
backend ValueObject for the SyntheticChildProvider. That's slightly crashy
because those expression value objects don't have the same lifetime guarantee
as their owner (they aren't part of the cluster manager). I fixed all the
other ways to make VO's in SyntheticChildProviders, but this one was
considerably more complicated and I ran out of time for that project, so that
bit's unfinished.
This didn't seem horrible to me because I don't think actually running code in
the target to format variables is something we should encourage.
I don't think it would be a great idea to mess with this API till it works
correctly, and then when you do that you are going to have to figure out how to
make the DIL expression result VO in this case belong to the ClusterManager of
an owning VO.
https://github.com/llvm/llvm-project/pull/222192
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
