REGRESSION(r168256): JSString can get 8-bit flag wrong when re-using AtomicStrings.
<https://webkit.org/b/133574>
<rdar://problem/18051847>
Source/JavaScriptCore:
The optimization that resolves JSRopeStrings into an existing
AtomicString (to save time and memory by avoiding StringImpl allocation)
had a bug that it wasn't copying the 8-bit flag from the AtomicString.
This could lead to a situation where a 16-bit StringImpl containing
only 8-bit characters is sitting in the AtomicString table, is found
by the rope resolution optimization, and gives you a rope that thinks
it's all 8-bit, but has a fiber with 16-bit characters.
Resolving that rope will then yield incorrect results.
This was all caught by an assertion, but very hard to reproduce.
Test: js/dopey-rope-with-16-bit-propertyname.html
Reviewed by Darin Adler.
* runtime/JSString.cpp:
(JSC::JSRopeString::resolveRopeToAtomicString):
(JSC::JSRopeString::resolveRopeToExistingAtomicString):
* runtime/JSString.h:
(JSC::JSString::setIs8Bit):
(JSC::JSString::toExistingAtomicString):
LayoutTests:
Add a tests that creates a 16-bit AtomicString with only 8-bit characters,
then tiers up into baseline JIT and uses that string as part of a rope-within-a-rope
and serializes that rope to get an incorrect concatenation.
Reviewed by Darin Adler.
* js/dopey-rope-with-16-bit-propertyname-expected.txt: Added.
* js/dopey-rope-with-16-bit-propertyname.html: Added.
git-svn-id: http://svn.webkit.org/repository/webkit/trunk@172727 268f45cc-cd09-0410-ab3c-d52691b4dbfc
6 files changed
