[lld] r232251 - [ELF] Fix DenseMapInfo for StringRef

[David Blaikie]

On Fri, Mar 13, 2015 at 10:26 PM, Shankar Easwaran <shankare at codeaurora.org>
wrote:

> Author: shankare
> Date: Sat Mar 14 00:26:55 2015
> New Revision: 232251
>
> URL: http://llvm.org/viewvc/llvm-project?rev=232251&view=rev
> Log:
> [ELF] Fix DenseMapInfo for StringRef
>
> Modified:
>     lld/trunk/lib/ReaderWriter/ELF/SectionChunks.h
>
> Modified: lld/trunk/lib/ReaderWriter/ELF/SectionChunks.h
> URL:
> http://llvm.org/viewvc/llvm-project/lld/trunk/lib/ReaderWriter/ELF/SectionChunks.h?rev=232251&r1=232250&r2=232251&view=diff
>
> ==============================================================================
> --- lld/trunk/lib/ReaderWriter/ELF/SectionChunks.h (original)
> +++ lld/trunk/lib/ReaderWriter/ELF/SectionChunks.h Sat Mar 14 00:26:55 2015
> @@ -574,7 +574,7 @@ private:
>
>    struct StringRefMappingInfo {
>      static StringRef getEmptyKey() { return StringRef(); }
> -    static StringRef getTombstoneKey() { return StringRef(" ", 0); }
> +    static StringRef getTombstoneKey() { return StringRef(" ", 1); }
>

These look really questionable/problematic - they're totally valid
StringRef values  - I imagine maybe using the max value for a pointer (or
for the length, or both) might be more suitable, but I haven't looked at a
variety of DenseMap tombstones, etc, to see what's common.


>      static unsigned getHashValue(StringRef const val) {
>        return llvm::HashString(val);
>      }
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150314/540961ce/attachment.html>