Bug 67979 - REGRESSION(94981): Non-JavaScriptCore builds cannot compile without compiling runtime/UString.cpp
Summary: REGRESSION(94981): Non-JavaScriptCore builds cannot compile without compiling...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: WebKit Review Bot
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-09-12 18:55 PDT by WebKit Review Bot
Modified: 2011-09-13 01:27 PDT (History)
6 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description WebKit Review Bot 2011-09-12 18:55:24 PDT
REGRESSION(94981): Non-JavaScriptCore builds cannot compile without compiling runtime/UString.cpp
Requested by jamesr_ on #webkit.
Comment 1 James Robinson 2011-09-12 18:59:05 PDT
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
Comment 2 James Robinson 2011-09-12 19:20:49 PDT
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?
Comment 3 Alexey Proskuryakov 2011-09-12 23:03:44 PDT
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.
Comment 4 Alexey Proskuryakov 2011-09-12 23:04:57 PDT
Sorry, I had absolutely no reason to complain - looks like there was no rollout. My apologies.
Comment 5 Gavin Barraclough 2011-09-13 01:27:59 PDT
> 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.