[Lldb-commits] [lldb] r150854 - in /lldb/trunk/test/functionalities/data-formatter/data-formatter-stl/map: TestDataFormatterStdMap.py main.cpp

[Enrico Granata]

On Feb 20, 2012, at 11:13 AM, Eric Christopher wrote:

> 
> On Feb 20, 2012, at 11:11 AM, Enrico Granata <granata.enrico at gmail.com> wrote:
> 
>> It is. Semantics being: if any item with key=8 is in the map, return a reference to it. If not, add a new item with key=8 and value=int()=0
>> 
>>> -    ii[8] = 0;
>>> +    ii[85] = 1234567;
>> 
>> After these changes, there is no item with key=8 in the map, hence the expression is going to cause the creation of such an item, with value=0. Thus, there should be no way to match 1234567 in the expression output :) 
>> 
> 
> Ah right. That's fair.
> 
>>> +        self.expect("expression ii[8]", matching=False, error=True,
>>> +                    substrs = ['1234567'])
>> 
>> For the test to succeed with ToT clang, one would have to remove the error=True clause from the expect() call, but that would cause the test to fail for everyone who *does not* have ToT clang (and I expect this latter to be a much wider audience than the former).
>> We should be checking for which version of clang built the binary and have two versions of this expect call in place, one with error=True for older-than-bug-fixing-clang and one without for bug-fixing-or-greater revisions, but I guess that only makes sense once people start adopting the new clang and complaining :-)
> 
> I was thinking that you could test the same thing using si[8] instead :)
> 

True, I am properly being overcautious repeating the test for ii, si, is and si :)

> Mostly given the lack of comments I'm not quite sure what you're expecting to be tested there.
> 

Basically, the synthetic children feature that has been in LLDB since last summer provides an indexing scheme for containers, independent of whatever overloaded operator[] they may/may not provide: object[NUM] is taken to mean: the NUM-th synthetic child of object. For STL containers and similar classes this provides for a very natural notation, where you can say:

std::vector<int> int_vector;
//blabla add some stuff to int_vector

(lldb) frame variable int_vector[0]
(int) int_vector[0] = 5

(if one were not using synthetic children, this notation would reference some internal implementation detail of the vector, which most probably is not what the user truly cares about)

while for vector and list the analogy works quite well, for maps this analogy can break:

std::map<string,string> ss;

(lldb) frame variable ss[0] <-- this is now accessing one of the items of the map, the first one you encounter when iterating over the map
of course, this "operator[]" is much different from std::map<string,string>::operator[] both for parameter types and for semantics. to access the "real" operator[] you need to use expression:

(lldb) expression ss["foo"]

now, as a speed-up, expression is meant to first check that one is not simply saying expression localVariable. if so, expression is meant to use the (faster and non-code-running) code path used by "frame variable localVariable" to perform its task.
this would mean that

(lldb) expression ss[0]

would actually work as an equivalent for
frame variable ss[0], shadowing the class-provided operator[]. now, imagine having

std::map<int,string> is;

(lldb) expression is[0] <-- this will not do what you expect!

hence, there is a flag that allows the expression command to actually ignore synthetic children when doing its "is it a local variable?" check.
the test case is testing that this flag works.

hope I did a good enough job of explaining the logic ;-)

> -eric
> 

- Enrico Granata

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20120220/471f11c4/attachment.html>