[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