Bug 67979 – REGRESSION(94981): Non-JavaScriptCore builds cannot compile without compiling runtime/UString.cpp

• Status: NEW
• Component: New Bugs

[WebKit Review Bot]

REGRESSION(94981): Non-JavaScriptCore builds cannot compile without compiling runtime/UString.cpp
Requested by jamesr_ on #webkit.

[James Robinson]

http://trac.webkit.org/changeset/94981 added a caller to UString::latin1() in YarrInterpreter.cpp.  UString::latin1() is defined in runtime/UString.cpp, as opposed to most UString functions which are defined in UString.h.  This creates a new build time dependency on runtime/ from yarr/ which didn't previously exist.  For ports that build (or can build) without JSC this is a bit tricky to resolve, since compiling UString.cpp requires building the rest of runtime/ and (it seems from a brief inspection) most of the rest of JSC.

One fix would be to use the wtf/text/ string types instead of JSC::UString inside of YARR. Another option would be to put the definition of latin1() in UString.h.

What is the expected dependency graph here between runtime/, wtf/ and yarr/?

See http://trac.webkit.org/changeset/94997

[James Robinson]

WTF::String has a latin1() that looks identical to UString's.  Would it make sense for CharAccess be implemented in terms of WTF::String or WTF::StringImpl instead of JSC::Ustring?

[Alexey Proskuryakov]

This shouldn't have resulted in a rollout. Non-JSC builds are not required to be maintained by core developers - this was a condition for admitting those in trunk.

[Alexey Proskuryakov]

Sorry, I had absolutely no reason to complain - looks like there was no rollout. My apologies.

[Gavin Barraclough]

> What is the expected dependency graph here between runtime/, wtf/ and yarr/?

yarr is dependent on much of the rest of JSC.  e.g. yarr has a JIT and as such makes use of JSC assemblers classes.  Personally I would be interesting in making yarr depend solely on wtf, but this would mean moving the JIT code generation infrastructure into wtf, and I'm not sure if I'd find support for that idea. :-)

> WTF::String has a latin1() that looks identical to UString's.  Would it make sense for CharAccess be implemented in terms of WTF::String or WTF::StringImpl instead of JSC::Ustring?

Yep, it should be possible to make this be in terms of StringImpl (or WTF::String, but StringImpl is used broadly throughout JSC & WTF::String isn't currently).

In the longer term, the plan is for UString to go away (we very nearly finished unifying UString & String some time back, but didn't quite get there), but CharAccess is a temporary class (a part of the process of introducing 8-bit string support to StringImpl), and CharAccess would likely be replaced by something that worked in terms of StringImpls or Strings anyway.