[StdLib] Incorrect results from `String.hasPrefix` and `hasSuffix`

[natecook1000]

As reported on the Swift forums, String.hasPrefix and String.hasSuffix sometimes have an incorrect result:

"\r\n".hasPrefix("\r")      // true
"\r\n".hasPrefix("\r"[...]) // false

"\r\n".hasSuffix("\n")      // true
"\r\n".hasSuffix("\n"[...]) // false

All four of these calls should return false, since those methods should be matching at the character level, not at the Unicode scalar level. The problem is in the String-specific overloads for hasPrefix and hasSuffix in StringLegacy.swift, which don't validate that the string passed as a parameter ends on a character boundary (when both strings are known to be NFC). The calls that pass a substring go to the StringProtocol-based overload, instead, which calls through to the Sequence method starts(with:).

Environment

• Swift main branch

[nishithshah2211]

@natecook1000 I'd like to attempt fixing this if you or anyone else is not already working on it.

[nishithshah2211]

Just to add another observation for this buggy behavior:

"\r\n".count // returns 1 - because \r\n is an extended grapheme cluster 
"hello\r\n".count // 6 
"\r\nhello\r\n".count // 7

"\r\nhello\r\n".hasPrefix("\r") // returns true, but it should be false since \r\n is an extended grapheme cluster and \r is not to be considered independent of the following \n

[nishithshah2211]

More puzzling and likely related behavior:

let s1 = "\r\n" + "cafe" + "\u{301}" + "\r\n"
let s2 = "\r\n" + "cafe" + "\r\n"

s1.count // returns 6
s2.count // returns 6

s1.hasPrefix("\r") // returns false
s2.hasPrefix("\r") // returns true

It seems related to the same above behavior, but let me know if this should be filed as a separate bug.

[natecook1000]

Thanks for looking into this, @nishithshah2211! All the counts in your examples look good, and the spurious true results are all the result of this bug. In the second example, including the decomposed "e\u{301}" in the string means that it isn't in NFC form, so the path that exposes the issue isn't taken.