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

[Ted Kremenek]

I can see a trivial workaround by sacrificing a bit of storage.  Wrap 
the int64_t in a struct, with extra bits to indicate whether it is a 
sentinel or a tombstone.  The storage requirements will likely be 
completely unnoticeable, especially since the map is temporary.

Jordan Rose wrote:
> 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.