<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Feb 20, 2012, at 11:13 AM, Eric Christopher wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div><br>On Feb 20, 2012, at 11:11 AM, Enrico Granata <<a href="mailto:granata.enrico@gmail.com">granata.enrico@gmail.com</a>> wrote:<br><br><blockquote type="cite">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<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">- ii[8] = 0;<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">+ ii[85] = 1234567;<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">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 :) <br></blockquote><blockquote type="cite"><br></blockquote><br>Ah right. That's fair.<br><br><blockquote type="cite"><blockquote type="cite">+ self.expect("expression ii[8]", matching=False, error=True,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">+ substrs = ['1234567'])<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">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).<br></blockquote><blockquote type="cite">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 :-)<br></blockquote><br>I was thinking that you could test the same thing using si[8] instead :)<br><br></div></blockquote><div><br></div><div>True, I am properly being overcautious repeating the test for ii, si, is and si :)</div><br><blockquote type="cite"><div>Mostly given the lack of comments I'm not quite sure what you're expecting to be tested there.<br><br></div></blockquote><div><br></div><div>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: <i>object</i>[NUM] is taken to mean: the NUM-th synthetic child of <i>object</i>. For STL containers and similar classes this provides for a very natural notation, where you can say:</div><div><br></div><div>std::vector<int> int_vector;</div><div>//blabla add some stuff to int_vector</div><div><br></div><div>(lldb) frame variable int_vector[0]</div><div>(int) int_vector[0] = 5</div><div><br></div><div>(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)</div><div><br></div><div>while for vector and list the analogy works quite well, for maps this analogy can break:</div><div><br></div><div>std::map<string,string> ss;</div><div><br></div><div>(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</div><div>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:</div><div><br></div><div>(lldb) expression ss["foo"]</div><div><br></div><div>now, as a speed-up, expression is meant to first check that one is not simply saying expression <i>localVariable. </i>if so, expression is meant to use the (faster and non-code-running) code path used by "frame variable <i>localVariable</i>" to perform its task.</div><div>this would mean that</div><div><br></div><div>(lldb) expression ss[0]</div><div><br></div><div>would actually work as an equivalent for</div><div>frame variable ss[0], shadowing the class-provided operator[]. now, imagine having</div><div><br></div><div>std::map<int,string> is;</div><div><br></div><div>(lldb) expression is[0] <-- this will not do what you expect!</div><div><br></div><div>hence, there is a flag that allows the expression command to actually ignore synthetic children when doing its "is it a local variable?" check.</div><div>the test case is testing that this flag works.</div><div><br></div><div>hope I did a good enough job of explaining the logic ;-)</div><br><blockquote type="cite"><div>-eric<br><br></div></blockquote></div><br><div>-<i> Enrico Granata</i></div><div><div><br></div></div></body></html>