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

Jordan Rose jordan_rose at apple.com
Tue Aug 14 09:17:38 PDT 2012


On Aug 13, 2012, at 10:22 PM, Ted Kremenek <kremenek at apple.com> wrote:

> Hi Richard,
> 
> Thanks for making great progress on this!  I agree with Richard Smith's suggestion about not using an std::map, but is there a reason to not just use a DenseMap to see if there are any enum collisions?  Fundamentally your algorithm is O(n*log n), not O(n).  Since you are converted everything to an int64_t, could you not just use a DenseMap<int64_t, EnumConstantDecl*>?  You could then iterate over the EnumConstantDecls in one linear pass, converting them to int64_t's on the fly for comparison purposes.  A few advantages I see are:

The reason Dmitri didn't use a DenseMap for his type-tag work is because DenseMap needs to reserve an "empty" value and a "tombstone" value. I assume the same problem applies here: all possible int64_t values are possible enum constants, and we don't know until we've seen all the enums which ones are available as empty or tombstone values. It's possible there's a way around this, though.



More information about the cfe-commits mailing list