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

[Enrico Granata]

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 :) 

> +        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 :-)

- Enrico Granata

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

> 
> On Feb 17, 2012, at 5:14 PM, Enrico Granata <granata.enrico at gmail.com> wrote:
> 
>> Correct indeed, if you consider 8 as "8th item". Not correct if you consider 8 as "item with key = 8" :) the test is checking that in fact 8 here is used in the second interpretation.
>> Once the clang fixes to templates debug info go mainstream, it will be necessary to remove error=True from this line. Other than test, the test logic now seems to be right.
> 
> Basically I was considering that it was failing before to be a bug(that's now fixed in ToT :). If it were si[8] I'd have understood, but ii is an int-int map and so isn't ii[8] valid?
> 
> -eric

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