This revision was automatically updated to reflect the committed changes.
Closed by commit rL299259: Stop calling ValueObject::SetName from synthetic
child providers (authored by tberghammer).
Changed prior to commit:
https://reviews.llvm.org/D31371?vs=93528&id=93704#toc
Repository:
rL LLVM
Thanks.
Jim
> On Mar 30, 2017, at 1:16 PM, Tamas Berghammer wrote:
>
> Created bug for exposing ValueObject::Clone as SB API:
> http://bugs.llvm.org/show_bug.cgi?id=32477
>
> On Thu, Mar 30, 2017 at 1:04 PM Jim Ingham via Phabricator
> wrote:
> jingham accepted this revision.
> jingham added
Created bug for exposing ValueObject::Clone as SB API:
http://bugs.llvm.org/show_bug.cgi?id=32477
On Thu, Mar 30, 2017 at 1:04 PM Jim Ingham via Phabricator <
revi...@reviews.llvm.org> wrote:
> jingham accepted this revision.
> jingham added a comment.
> This revision is now accepted and ready to
jingham accepted this revision.
jingham added a comment.
This revision is now accepted and ready to land.
Good.
https://reviews.llvm.org/D31371
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/
I see. Might be worth filing an enhancement request to expose Clone so you can
do this in a Python synthetic child provider. But there's no reason that lack
should block this change.
Jim
> On Mar 30, 2017, at 12:51 PM, Tamas Berghammer wrote:
>
> It is possible to vend one of the actual bac
tberghammer updated this revision to Diff 93528.
tberghammer added a comment.
Fix typos in the comments
https://reviews.llvm.org/D31371
Files:
include/lldb/Core/ValueObject.h
source/Core/ValueObject.cpp
source/DataFormatters/VectorType.cpp
source/Plugins/Language/CPlusPlus/LibCxxMap.cpp
It is possible to vend one of the actual backing object as a synthetic
child using the SB API. What is not possible from the SB API at the moment
(we might want to fix it) is to vend one of the actual backing object with
a different name then the underlying object itself. You can still say that
obj
> On Mar 29, 2017, at 2:06 AM, Tamas Berghammer via Phabricator
> wrote:
>
> tberghammer added a comment.
>
> SBValue::SetName is not part of the SB API (what is the right decision IMO as
> an SBValue should be mostly immutable) so this issue doesn't effect it. I
> looked through the code in
tberghammer added a comment.
SBValue::SetName is not part of the SB API (what is the right decision IMO as
an SBValue should be mostly immutable) so this issue doesn't effect it. I
looked through the code in examples/synthetic/gnu_libstdcpp.py and it is always
using one of the SBValue::Create*
jingham requested changes to this revision.
jingham added a comment.
This revision now requires changes to proceed.
If SetName is the wrong thing to use for synthetic child providers, then we
need to make Clone available to the SB API's as well. In any case where they
want to return an extant V
tberghammer created this revision.
Calling ValueObject::SetName from a sythetic child provider would change
the underying value object used for the non-synthetic child as well what
is clearly unintentional.
https://reviews.llvm.org/D31371
Files:
include/lldb/Core/ValueObject.h
source/Core/V
11 matches
Mail list logo
