Use the code point iterator when computing 16-bit string hash codes.

runtime/vm/unicode.h

Index: runtime/vm/unicode.h
diff --git a/runtime/vm/unicode.h b/runtime/vm/unicode.h
index 03a4b29d879898c2c83f06aac4a175d4729db209..2d190bdddc3f6b85f97c7a7e0141871fa705d3f3 100644
--- a/runtime/vm/unicode.h
+++ b/runtime/vm/unicode.h
@@ -93,6 +93,22 @@ class Utf16 : AllStatic {
     return (ch & 0xFFFFFC00) == 0xDC00;
   }
 
+  // Returns the character at i and advances i to the next character
+  // boundary.
+  static int32_t Next(const uint16_t* characters, intptr_t* i, intptr_t len) {
+    int32_t ch = characters[*i];
+    if (Utf16::IsLeadSurrogate(ch) && (*i < (len - 1))) {
+      int32_t ch2 = characters[*i + 1];
+      if (Utf16::IsTrailSurrogate(ch2)) {
+        ch = Utf16::Decode(ch, ch2);
+        *i += 2;
+      }
+    } else {
+      *i += 1;
+    }
+    return ch;
+  }

[siva, 2012/11/30 02:00:19]

I am wondering if it would make sense to add an iterator here which iterates
over UTF16 characters and use that in
intptr_t String::Hash(const uint16_t* characters, intptr_t len)

Søren's CL also seems to indicate the need for it.

[cshapiro, 2012/11/30 02:28:22]

Hmm... the code point iterator is rather bulky.  I think we can get away with
something smaller since we have the address of the character data.

+
   // Decodes a surrogate pair into a supplementary code point.
   static int32_t Decode(int32_t lead, int32_t trail) {
     return 0x10000 + ((lead & 0x3FF) << 10) + (trail & 0x3FF);