[cfe-commits] [Patch] -Wduplicate-enum which fixes PR6343

[Ted Kremenek]

On Aug 14, 2012, at 2:32 PM, Richard Trieu <rtrieu at google.com> wrote:

> 
> At a high level, I honestly find this logic to be more complicated than I would have expected.  The sorting seems unnecessary, and will report diagnostics in an unnatural order (first based on enum constant value, then on declaration order).  A straight linear pass seems more naturally to me, and DenseMap is very efficient.
> Is there a comparison between the different containers in LLVM and the STL containers?  Also, will the DenseMap fix the unnatural order of the diagnostics?
>  

With respect to the order of diagnostics, my thought is the container that you use to determine if there are duplicates does not impact the order to issue diagnostics.

Here's one possible algorithm:

(1) Iterate through each EnumConstantDecl in *declaration order*.

For each EnumConstantDecl, consult the DenseMap to count occurrences.  When an occurrence exceeds 1, change the DenseMap data value to instead be an index into another data structure that is *lazily* constructed.  That data structure contains the first EnumConstantDecl we encountered for that constant value, and a sequence of all the other EnumConstantDecls that had the same value.

(2) Iterate over the second data structure, and print out the warnings.


This leads to a linear time algorithm where the diagnostics are printed in the order that EnumConstantDecls appear in the source code.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120814/652b6f89/attachment.html>