-
barraclough@apple.com authored
rather than returning a null string (which will behave like a zero-length string if used). Reviewed by Geoff Garen. Also move createRep function from UString to become new overloaded UStringImpl::create methods. In doing so, bring their behaviour closer to being in line with WebCore::StringImpl, in removing the behaviour that they can be used to produce null UStrings (ASSERT the char* provided is non-null). This behaviour of converting null C-strings to null UStrings is inefficient (cmompared to just using UString::null()), incompatible with WebCore::StringImpl's behaviour, and may generate unexpected behaviour, since in many cases a null UString can be used like an empty string. With these changes UStringImpl need not have a concept of null impls, we can start transitioning this to become an implementation detail of UString, that internally it chooses to use a null-object rather than an actually zero impl pointer. * JavaScriptCore.exp: * debugger/Debugger.cpp: (JSC::Debugger::recompileAllJSFunctions): * debugger/DebuggerCallFrame.cpp: (JSC::DebuggerCallFrame::calculatedFunctionName): * parser/Parser.cpp: (JSC::Parser::parse): * profiler/Profile.cpp: (JSC::Profile::Profile): * profiler/ProfileGenerator.cpp: (JSC::ProfileGenerator::stopProfiling): * runtime/Error.cpp: (JSC::Error::create): (JSC::throwError): * runtime/ExceptionHelpers.cpp: (JSC::createError): * runtime/Identifier.cpp: (JSC::Identifier::add): * runtime/PropertyNameArray.cpp: (JSC::PropertyNameArray::add): * runtime/UString.cpp: (JSC::initializeUString): (JSC::UString::UString): (JSC::UString::operator=): * runtime/UString.h: (JSC::UString::isNull): (JSC::UString::null): (JSC::UString::rep): (JSC::UString::UString): * runtime/UStringImpl.cpp: (JSC::UStringImpl::create): * runtime/UStringImpl.h: git-svn-id: http://svn.webkit.org/repository/webkit/trunk@54464 268f45cc-cd09-0410-ab3c-d52691b4dbfc
e37590bc