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.
Details
Diff Detail
- Build Status
Buildable 5089 Build 5089: arc lint + arc unit
Event Timeline
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 ValueObject with a different name - as opposed to making one up out of whole cloth - won't they need the same operation?
Also, probably should document this requirement in the varformats.html.
include/lldb/Core/ValueObject.h | ||
---|---|---|
607–610 | Spelling... "he" -> "the", "chane" -> "change", "actul" -> "actual" |
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* method to produce new SBValue what will create a new value object one way or the other. Considering that nobody complained about the missing SetName method at the SB API level I don't see a big need for exposing the Clone method there. At the same line if SetName/Clone isn't part of the SB API then I think we shouldn't document it at the webpage.
(I will upload a fix for the spelling errors later)
Spelling... "he" -> "the", "chane" -> "change", "actul" -> "actual"