A set could work for detecting the values, but both EnumConstantDecls are needed for the diagnostic, not just the values.  Possibly a map from APSInt->EnumConstantDecl* would work.  But either way, I would be dealing with getting APSInts to play nice with each other.<br>
<br><div class="gmail_quote">On Wed, Jul 18, 2012 at 6:16 PM, Sean Silva <span dir="ltr"><<a href="mailto:silvas@purdue.edu" target="_blank">silvas@purdue.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Why not just keep a set containing all previously seen values? Then<br>
you can find duplicates with a linear scan.<br>
<span><font color="#888888"><br>
--Sean Silva<br>
</font></span><div><div><br>
On Wed, Jul 18, 2012 at 6:11 PM, Richard Trieu <<a href="mailto:rtrieu@google.com" target="_blank">rtrieu@google.com</a>> wrote:<br>
> On Wed, Jul 18, 2012 at 5:41 PM, Ted Kremenek <<a href="mailto:kremenek@apple.com" target="_blank">kremenek@apple.com</a>> wrote:<br>
>><br>
>> Hi Richard,<br>
>><br>
>> I think this checking is quadratic, n(n+1)/2.<br>
><br>
> Yes it is.  It does perform a check between each enum in the worst case.<br>
><br>
>><br>
>>  This might be fairly expensive on a large set of enums.  Do you have any<br>
>> performance numbers?<br>
><br>
> I haven't run any performance tests.  I will try running some when I get the<br>
> chance.<br>
><br>
>><br>
>>  I agree that it is a good checking, but the way it is implemented is<br>
>> likely to be noticeably slow on some (important) cases.<br>
><br>
> How many elements in an enum would be in these important cases?<br>
>><br>
>><br>
>> Ted<br>
>><br>
>> On Jul 18, 2012, at 4:46 PM, Richard Trieu <<a href="mailto:rtrieu@google.com" target="_blank">rtrieu@google.com</a>> wrote:<br>
>><br>
>> <a href="http://llvm.org/bugs/show_bug.cgi?id=6343" target="_blank">http://llvm.org/bugs/show_bug.cgi?id=6343</a><br>
>><br>
>> Warn on enum elements that are assigned values already in use.  This is<br>
>> based on the misconception that elements not given a value will be given the<br>
>> next smallest, unused value.  Instead, elements are assigned 1 more than the<br>
>> previous value.  Some example code this warning will catch:<br>
>><br>
>> enum { A, B, C, Aref = A, count };<br>
>> Both B and count will have value 1.<br>
>><br>
>> enum { A, B, C, D = -1, E, F };<br>
>> A = E = 0<br>
>> B = F = 1<br>
>><br>
>> This warning found one such issue in LLVM that was fixed in r160465.<br>
>> <duplicate-enum.patch>_______________________________________________<br>
>> cfe-commits mailing list<br>
>> <a href="mailto:cfe-commits@cs.uiuc.edu" target="_blank">cfe-commits@cs.uiuc.edu</a><br>
>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits</a><br>
>><br>
>><br>
><br>
><br>
> _______________________________________________<br>
> cfe-commits mailing list<br>
> <a href="mailto:cfe-commits@cs.uiuc.edu" target="_blank">cfe-commits@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits</a><br>
><br>
</div></div></blockquote></div><br>