Expand WTF::StringView's API to be more like StringPiece.

Expand WTF::StringView's API to be more like StringPiece.

StringView no longer owns the string passed into it, and can now wrap
a raw ptr to some characters.

This allows us to leverage the inline strlen optimization where the
compiler will embed the length of literal strings into the binary. It
also allows the deletion many overloaded methods that used to take
an LChar*, UChar* or String and can now just take a StringView instead.

For example the two constructors in TextRun are now a single one that
takes a StringView. This needed to be done in this patch to avoid
ambiguous constructors.

Future patches will replace CSSParserString with StringView, and also
vastly simplify the huge number of overloads on various methods. We'll
also expand the API surface of StringView to include the many useful
operations that StringPiece has.

This was originally committed as:
https://crrev.com/330deea56e27bc760fa52101040a51428bb7f582 but was
reverted due an incorrect assert in the
StringView(const UChar*, unsigned length) constructor. The assert
was incorrectly calling lengthOfNullTerminatedString on the UChar
in the assert, but this constructor is used for byte sequences which
are not null terminated.

BUG=615174
Committed: https://crrev.com/9b0aad1eca55ac75f437789514224e9b922fe514
Cr-Commit-Position: refs/heads/master@{#396942}

[esprehn, 2016-05-26 02:22:23]

The CQ bit was checked by esprehn@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-05-26 02:22:45]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2007103003/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/2007103003/20001

[commit-bot: I haz the power, 2016-05-26 02:52:58]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-05-26 02:52:59]

Dry run: Try jobs failed on following builders:
  android_compile_dbg on tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_comp...)

[esprehn, 2016-05-26 04:15:16]

Description was changed from

==========
Expand WTF::StringView's API to be more like StringPiece.

BUG=
==========

to

==========
Expand WTF::StringView's API to be more like StringPiece.

StringView no longer owns the string passed into it, and can now wrap
a raw ptr to some characters.

This allows us to leverage the inline strlen optimization where the
compiler will embed the length of literal strings into the binary. It
also allows the deletion many overloaded methods that used to take
an LChar*, UChar* or String and can now just take a StringView instead.

For example the two constructors in TextRun are now a single one that
takes a StringView. This needed to be done in this patch to avoid
ambiguous constructors.
==========

[esprehn, 2016-05-26 20:06:45]

The CQ bit was checked by esprehn@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-05-26 20:07:17]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2007103003/80001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/2007103003/80001

[esprehn, 2016-05-26 20:11:54]

Description was changed from

==========
Expand WTF::StringView's API to be more like StringPiece.

StringView no longer owns the string passed into it, and can now wrap
a raw ptr to some characters.

This allows us to leverage the inline strlen optimization where the
compiler will embed the length of literal strings into the binary. It
also allows the deletion many overloaded methods that used to take
an LChar*, UChar* or String and can now just take a StringView instead.

For example the two constructors in TextRun are now a single one that
takes a StringView. This needed to be done in this patch to avoid
ambiguous constructors.
==========

to

==========
Expand WTF::StringView's API to be more like StringPiece.

StringView no longer owns the string passed into it, and can now wrap
a raw ptr to some characters.

This allows us to leverage the inline strlen optimization where the
compiler will embed the length of literal strings into the binary. It
also allows the deletion many overloaded methods that used to take
an LChar*, UChar* or String and can now just take a StringView instead.

For example the two constructors in TextRun are now a single one that
takes a StringView. This needed to be done in this patch to avoid
ambiguous constructors.

Future patches will replace CSSParserString with StringView, and also
vastly simplify the huge number of overloads on various methods. We'll
also expand the API surface of StringView to include the many useful
operations that StringPiece has.

BUG=615174
==========

[esprehn, 2016-05-26 20:57:52]

esprehn@chromium.org changed reviewers:
+ haraken@chromium.org, jyasskin@chromium.org, yutak@chromium.org

[esprehn, 2016-05-26 20:59:08]

https://codereview.chromium.org/2007103003/diff/80001/third_party/WebKit/Sour...
File third_party/WebKit/Source/wtf/text/StringBuilder.h (left):

https://codereview.chromium.org/2007103003/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/wtf/text/StringBuilder.h:60: if (!m_length &&
!m_buffer) {
I did actually remove this optimization, but I audited the code and it doesn't
seem like this ever gets used. Plus doing another append() would require a
realloc anyway, and almost all of the usage of this method are doing multiple
appends, so doing an initial alloc with some extra space is probably worth it.

[haraken, 2016-05-26 22:27:22]

LGTM

https://codereview.chromium.org/2007103003/diff/80001/third_party/WebKit/Sour...
File third_party/WebKit/Source/wtf/text/StringView.cpp (right):

https://codereview.chromium.org/2007103003/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/wtf/text/StringView.cpp:25: if (!m_data.bytes)

isNull()

https://codereview.chromium.org/2007103003/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/wtf/text/StringView.cpp:37: return a.isNull() ==
b.isNull();

A better check would be:

  if (a.length() == 0 || b.length() == 0)
    return a.length() == b.length();

?

Then we can cover empty strings.

https://codereview.chromium.org/2007103003/diff/80001/third_party/WebKit/Sour...
File third_party/WebKit/Source/wtf/text/StringView.h (right):

https://codereview.chromium.org/2007103003/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/wtf/text/StringView.h:80: bool isEmpty() const {
return !m_length; }

I'm not sure if we need to distinguish a null StringView from an empty
StringView.

https://codereview.chromium.org/2007103003/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/wtf/text/StringView.h:149: // calls to equal() that
pass literal strings ambigious. Figure out if we can

ambiguous

[esprehn, 2016-05-26 22:40:00]

The CQ bit was unchecked by esprehn@chromium.org

[esprehn, 2016-05-26 22:40:22]

ASAN bot also seems to have found a bug:

==28713==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60d00000b864
at pc 0x000000549e50 bp 0x7ffd2575edd0 sp 0x7ffd2575e580
READ of size 82 at 0x60d00000b864 thread T0
    #0 0x549e4f in __interceptor_strlen
(/tmp/runs1n1CA/out/Release/webkit_unit_tests+0x549e4f)
    #1 0x7b643d3 in StringView
third_party/WebKit/Source/wtf/text/StringView.h:137:5
    #2 0x7b643d3 in operator StringView
third_party/WebKit/Source/core/css/parser/CSSParserString.h:97
    #3 0x7b643d3 in blink::concatenateFamilyName(blink::CSSParserTokenRange&)
third_party/WebKit/Source/core/css/parser/CSSPropertyParser.cpp:692
    #4 0x7b447cb in blink::consumeFamilyName(blink::CSSParserTokenRange&)
third_party/WebKit/Source/core/css/parser/CSSPropertyParser.cpp:705:25
    #5 0x7b2d530 in
blink::CSSPropertyParser::parseFontFaceDescriptor(blink::CSSPropertyID)
third_party/WebKit/Source/core/css/parser/CSSPropertyParser.cpp:4057:23
    #6 0x7b2c91a in blink::CSSPropertyParser::parseValue(blink::CSSPropertyID,
bool, blink::CSSParserTokenRange const&, blink::CSSParserContext const&,
blink::HeapVector<blink::CSSProperty, 256ul>&, blink::StyleRuleBase::RuleType)
third_party/WebKit/Source/core/css/parser/CSSPropertyParser.cpp:116:24


I'm investigating. I'll write some tests too.

https://codereview.chromium.org/2007103003/diff/80001/third_party/WebKit/Sour...
File third_party/WebKit/Source/wtf/text/StringView.cpp (right):

https://codereview.chromium.org/2007103003/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/wtf/text/StringView.cpp:25: if (!m_data.bytes)
On 2016/05/26 at 22:27:22, haraken wrote:
> isNull()

done, also added a case for empty strings.

https://codereview.chromium.org/2007103003/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/wtf/text/StringView.cpp:37: return a.isNull() ==
b.isNull();
On 2016/05/26 at 22:27:22, haraken wrote:
> A better check would be:
> 
>   if (a.length() == 0 || b.length() == 0)
>     return a.length() == b.length();
> 
> ?
> 
> Then we can cover empty strings.

Yeah, checking isEmpty() works here.

https://codereview.chromium.org/2007103003/diff/80001/third_party/WebKit/Sour...
File third_party/WebKit/Source/wtf/text/StringView.h (right):

https://codereview.chromium.org/2007103003/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/wtf/text/StringView.h:80: bool isEmpty() const {
return !m_length; }
On 2016/05/26 at 22:27:22, haraken wrote:
> I'm not sure if we need to distinguish a null StringView from an empty
StringView.

This has the same semantics as String, which are needed to make this a drop in
replacement.

isEmpty() == (isNull() || length() == 0)

See WTFString.h's isNull().

[commit-bot: I haz the power, 2016-05-26 22:40:25]

Dry run: None

[haraken, 2016-05-26 22:45:25]

https://codereview.chromium.org/2007103003/diff/80001/third_party/WebKit/Sour...
File third_party/WebKit/Source/wtf/text/StringView.h (right):

https://codereview.chromium.org/2007103003/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/wtf/text/StringView.h:80: bool isEmpty() const {
return !m_length; }
On 2016/05/26 22:40:21, esprehn wrote:
> On 2016/05/26 at 22:27:22, haraken wrote:
> > I'm not sure if we need to distinguish a null StringView from an empty
> StringView.
> 
> This has the same semantics as String, which are needed to make this a drop in
> replacement.
> 
> isEmpty() == (isNull() || length() == 0)
> 
> See WTFString.h's isNull().

Yes, but that's an optimization for WTFString to avoid creating an unnecessary
StringImpl object. StringView doesn't hold a StringImpl object, so I'm not sure
if we need to distinguish isNull() and isEmpty().

[esprehn, 2016-05-26 22:45:25]

The bug that ASAN caught is that the constructor StringView(const LChar* chars,
unsigned length) had this assert:

    SECURITY_DCHECK(!chars || length <= strlen(reinterpret_cast<const
char*>(chars)));

but you can't assert with strlen here since some callers are creating
StringViews for non-null terminated strings, for example the CSSParser does
this. I just removed the assert instead. There's no way to assert that this
constructor is called with a valid length since C++ doesn't have a literal
string type.

[haraken, 2016-05-26 22:47:39]

On 2016/05/26 22:45:25, esprehn wrote:
> The bug that ASAN caught is that the constructor StringView(const LChar*
chars,
> unsigned length) had this assert:
> 
>     SECURITY_DCHECK(!chars || length <= strlen(reinterpret_cast<const
> char*>(chars)));
> 
> but you can't assert with strlen here since some callers are creating
> StringViews for non-null terminated strings, for example the CSSParser does
> this. I just removed the assert instead. There's no way to assert that this
> constructor is called with a valid length since C++ doesn't have a literal
> string type.

Can we force a null termination for those strings?

[esprehn, 2016-05-26 22:48:40]

https://codereview.chromium.org/2007103003/diff/80001/third_party/WebKit/Sour...
File third_party/WebKit/Source/wtf/text/StringView.h (right):

https://codereview.chromium.org/2007103003/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/wtf/text/StringView.h:80: bool isEmpty() const {
return !m_length; }
On 2016/05/26 at 22:45:24, haraken wrote:
> On 2016/05/26 22:40:21, esprehn wrote:
> > ...
> > 
> > This has the same semantics as String, which are needed to make this a drop
in
> > replacement.
> > 
> > isEmpty() == (isNull() || length() == 0)
> > 
> > See WTFString.h's isNull().
> 
> Yes, but that's an optimization for WTFString to avoid creating an unnecessary
StringImpl object. StringView doesn't hold a StringImpl object, so I'm not sure
if we need to distinguish isNull() and isEmpty().

We do need to, otherwise code like ScriptRegexp::match can't use StringView
since the web has different behavior for null vs empty.

ex of ScriptRegex:

/^$/.test("") => true
/^$/.test(null) => false

[esprehn, 2016-05-26 22:57:41]

https://codereview.chromium.org/2007103003/diff/80001/third_party/WebKit/Sour...
File third_party/WebKit/Source/wtf/text/StringView.h (right):

https://codereview.chromium.org/2007103003/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/wtf/text/StringView.h:80: bool isEmpty() const {
return !m_length; }
On 2016/05/26 at 22:48:40, esprehn wrote:
> ...
> 
> ex of ScriptRegex:
> 
> /^$/.test("") => true
> /^$/.test(null) => false

literally ScriptRegex would be:

ScriptRegexp("^$", TextCaseSensitive).match(String("")) => 0
ScriptRegexp("^$", TextCaseSensitive).match(String()) => -1

[haraken, 2016-05-26 22:58:42]

On 2016/05/26 22:57:41, esprehn wrote:
>
https://codereview.chromium.org/2007103003/diff/80001/third_party/WebKit/Sour...
> File third_party/WebKit/Source/wtf/text/StringView.h (right):
> 
>
https://codereview.chromium.org/2007103003/diff/80001/third_party/WebKit/Sour...
> third_party/WebKit/Source/wtf/text/StringView.h:80: bool isEmpty() const {
> return !m_length; }
> On 2016/05/26 at 22:48:40, esprehn wrote:
> > ...
> > 
> > ex of ScriptRegex:
> > 
> > /^$/.test("") => true
> > /^$/.test(null) => false
> 
> literally ScriptRegex would be:
> 
> ScriptRegexp("^$", TextCaseSensitive).match(String("")) => 0
> ScriptRegexp("^$", TextCaseSensitive).match(String()) => -1

Makes sense.

[esprehn, 2016-05-27 03:39:27]

The CQ bit was checked by esprehn@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-05-27 03:39:48]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2007103003/140001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/2007103003/140001

[commit-bot: I haz the power, 2016-05-27 04:42:50]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-05-27 04:42:52]

Dry run: Try jobs failed on following builders:
  linux_chromium_asan_rel_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[Yuta Kitamura, 2016-05-27 04:47:41]

Generally seems okay but I'm concerned about having inlined
definitions in different headers.

https://codereview.chromium.org/2007103003/diff/140001/third_party/WebKit/Sou...
File third_party/WebKit/Source/wtf/text/StringView.cpp (right):

https://codereview.chromium.org/2007103003/diff/140001/third_party/WebKit/Sou...
third_party/WebKit/Source/wtf/text/StringView.cpp:50: return
WTF::equal(a.characters8(), b.characters8(), a.length());
nit: Omit "WTF::".

https://codereview.chromium.org/2007103003/diff/140001/third_party/WebKit/Sou...
File third_party/WebKit/Source/wtf/text/WTFString.h (right):

https://codereview.chromium.org/2007103003/diff/140001/third_party/WebKit/Sou...
third_party/WebKit/Source/wtf/text/WTFString.h:672: : StringView(string.impl(),
offset) {}
Having inline definitions of StringView here looks strange.
If some files just include StringView.h but not WTFString.h,
uses of these constructors there will not get inlined
and you might end up weird link errors.

How about reversing the include dependency, i.e. remove
#include "wtf/StringView.h" from here and add #include
"WTFString.h" in StringView.h, and move the inline
definitions there? I think that's more natural and
intuitive.

This also applies other inlined constructors.

[esprehn, 2016-05-27 05:31:28]

Hmm, so all the tests pass on my machine, but the character ptr to StringView
comparisons fail:

[ RUN      ] StringViewTest.ConstructionStringImpl8
../../third_party/WebKit/Source/wtf/text/StringViewTest.cpp:34: Failure
Value of: StringView(impl8Bit.get(), 2).characters8()
  Actual: 0x1fea7b62c0c6
Expected: StringView("345")

The code is:

const char* kChars = "12345";
const LChar* kChars8 = reinterpret_cast<const LChar*>(kChars);
RefPtr<StringImpl> impl8Bit = StringImpl::create(kChars8, 5);
EXPECT_EQ(StringView("345"), StringView(impl8Bit.get(), 2).characters8());

which should expand to:

StringView("345") == StringView(impl8Bit.get(), 2).characters8()

and the implicitly construct a StringView as:

StringView("345") == StringView(StringView(impl8Bit.get(), 2).characters8())

I'm not sure what's on my local macbook vs the bots, but all the various
construction tests fail that step on Mac, Windows and Linux.

[esprehn, 2016-05-27 05:57:24]

I figured this out, you can never implicitly construct a StringView (or String,
AtomicString, etc.) from the result of characters8() or characters16() since
they're not actually null terminated. This probably worked locally for me
because PartitionAlloc happened to have zeros there, when you compile with
assertions on (like the bots), or you build debug, PartitionAlloc leaves poison
markers around all the allocations which immediately catches this since
strlen(string.characters8()) starts returning some number much larger than the
string.

[esprehn, 2016-05-27 05:57:43]

The CQ bit was checked by esprehn@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-05-27 05:58:00]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2007103003/160001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/2007103003/160001

[esprehn, 2016-05-27 06:22:23]

On 2016/05/27 at 04:47:41, yutak wrote:
> Generally seems okay but I'm concerned about having inlined
> definitions in different headers.
> 

I did that because otherwise you can't have inline methods/functions on String,
StringImpl or AtomicString that take a StringView since that would create a
cyclic header dependency. Looking now I think we should probably move the
various string operations to separate files like equalsIgnoringCase() should be
in a StringOperations.h.

I'll move the constructors to StringView.h and see where I get stuck as I start
landing patches after this one. :)

[commit-bot: I haz the power, 2016-05-27 08:10:36]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-05-27 08:10:37]

Dry run: This issue passed the CQ dry run.

[esprehn, 2016-05-27 08:24:44]

The CQ bit was checked by esprehn@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-05-27 08:24:57]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2007103003/180001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/2007103003/180001

[esprehn, 2016-05-27 08:42:45]

The CQ bit was checked by esprehn@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-05-27 08:42:57]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2007103003/220001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/2007103003/220001

[esprehn, 2016-05-27 08:44:51]

Okay this is ready for a review from everyone. Once this lands I'll start adding
more methods to it and replacing lots of the overload sets around the codebase
with it. I think we can remove a ton of duplicate code.

[Yuta Kitamura, 2016-05-27 09:11:22]

lgtm

[commit-bot: I haz the power, 2016-05-27 10:38:19]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-05-27 10:38:21]

Dry run: This issue passed the CQ dry run.

[esprehn, 2016-05-27 16:52:47]

jyasskin@ said to go ahead and land this, he can add comments after if needed
and I'll fix in follow ups. :)

[esprehn, 2016-05-27 16:52:52]

The CQ bit was checked by esprehn@chromium.org

[esprehn, 2016-05-27 16:52:52]

The patchset sent to the CQ was uploaded after l-g-t-m from haraken@chromium.org
Link to the patchset: https://codereview.chromium.org/2007103003/#ps220001
(title: "Add comments.")

[commit-bot: I haz the power, 2016-05-27 16:53:11]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2007103003/220001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/2007103003/220001

[commit-bot: I haz the power, 2016-05-27 16:58:32]

Committed patchset #12 (id:220001)

[commit-bot: I haz the power, 2016-05-27 17:00:23]

Description was changed from

==========
Expand WTF::StringView's API to be more like StringPiece.

StringView no longer owns the string passed into it, and can now wrap
a raw ptr to some characters.

This allows us to leverage the inline strlen optimization where the
compiler will embed the length of literal strings into the binary. It
also allows the deletion many overloaded methods that used to take
an LChar*, UChar* or String and can now just take a StringView instead.

For example the two constructors in TextRun are now a single one that
takes a StringView. This needed to be done in this patch to avoid
ambiguous constructors.

Future patches will replace CSSParserString with StringView, and also
vastly simplify the huge number of overloads on various methods. We'll
also expand the API surface of StringView to include the many useful
operations that StringPiece has.

BUG=615174
==========

to

==========
Expand WTF::StringView's API to be more like StringPiece.

StringView no longer owns the string passed into it, and can now wrap
a raw ptr to some characters.

This allows us to leverage the inline strlen optimization where the
compiler will embed the length of literal strings into the binary. It
also allows the deletion many overloaded methods that used to take
an LChar*, UChar* or String and can now just take a StringView instead.

For example the two constructors in TextRun are now a single one that
takes a StringView. This needed to be done in this patch to avoid
ambiguous constructors.

Future patches will replace CSSParserString with StringView, and also
vastly simplify the huge number of overloads on various methods. We'll
also expand the API surface of StringView to include the many useful
operations that StringPiece has.

BUG=615174

Committed: https://crrev.com/330deea56e27bc760fa52101040a51428bb7f582
Cr-Commit-Position: refs/heads/master@{#396493}
==========

[commit-bot: I haz the power, 2016-05-27 17:00:26]

Patchset 12 (id:??) landed as
https://crrev.com/330deea56e27bc760fa52101040a51428bb7f582
Cr-Commit-Position: refs/heads/master@{#396493}

[sof, 2016-05-28 11:38:05]

A revert of this CL (patchset #12 id:220001) has been created in
https://codereview.chromium.org/2025503002/ by sigbjornf@opera.com.

The reason for reverting is: Many a heap-buffer-overflow ASan failures,
 

https://build.chromium.org/p/chromium.webkit/builders/WebKit%20Linux%20ASAN/b....

[esprehn, 2016-05-31 19:43:08]

The CQ bit was checked by esprehn@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-05-31 19:44:13]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2007103003/240001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/2007103003/240001

[esprehn, 2016-05-31 20:23:11]

The CQ bit was unchecked by esprehn@chromium.org

[esprehn, 2016-05-31 20:24:36]

Description was changed from

==========
Expand WTF::StringView's API to be more like StringPiece.

StringView no longer owns the string passed into it, and can now wrap
a raw ptr to some characters.

This allows us to leverage the inline strlen optimization where the
compiler will embed the length of literal strings into the binary. It
also allows the deletion many overloaded methods that used to take
an LChar*, UChar* or String and can now just take a StringView instead.

For example the two constructors in TextRun are now a single one that
takes a StringView. This needed to be done in this patch to avoid
ambiguous constructors.

Future patches will replace CSSParserString with StringView, and also
vastly simplify the huge number of overloads on various methods. We'll
also expand the API surface of StringView to include the many useful
operations that StringPiece has.

BUG=615174

Committed: https://crrev.com/330deea56e27bc760fa52101040a51428bb7f582
Cr-Commit-Position: refs/heads/master@{#396493}
==========

to

==========
Expand WTF::StringView's API to be more like StringPiece.

StringView no longer owns the string passed into it, and can now wrap
a raw ptr to some characters.

This allows us to leverage the inline strlen optimization where the
compiler will embed the length of literal strings into the binary. It
also allows the deletion many overloaded methods that used to take
an LChar*, UChar* or String and can now just take a StringView instead.

For example the two constructors in TextRun are now a single one that
takes a StringView. This needed to be done in this patch to avoid
ambiguous constructors.

Future patches will replace CSSParserString with StringView, and also
vastly simplify the huge number of overloads on various methods. We'll
also expand the API surface of StringView to include the many useful
operations that StringPiece has.

This was originally committed as:
https://crrev.com/330deea56e27bc760fa52101040a51428bb7f582
but was reverted due an incorrect assert in the
StringView(const UChar*, unsigned length) constructor. The
assert was incorrectly calling lengthOfNullTerminatedString
on the UChar in the assert, but this constructor is used for
byte sequences which are not null terminated.

BUG=615174
==========

[esprehn, 2016-05-31 20:25:00]

Description was changed from

==========
Expand WTF::StringView's API to be more like StringPiece.

StringView no longer owns the string passed into it, and can now wrap
a raw ptr to some characters.

This allows us to leverage the inline strlen optimization where the
compiler will embed the length of literal strings into the binary. It
also allows the deletion many overloaded methods that used to take
an LChar*, UChar* or String and can now just take a StringView instead.

For example the two constructors in TextRun are now a single one that
takes a StringView. This needed to be done in this patch to avoid
ambiguous constructors.

Future patches will replace CSSParserString with StringView, and also
vastly simplify the huge number of overloads on various methods. We'll
also expand the API surface of StringView to include the many useful
operations that StringPiece has.

This was originally committed as:
https://crrev.com/330deea56e27bc760fa52101040a51428bb7f582
but was reverted due an incorrect assert in the
StringView(const UChar*, unsigned length) constructor. The
assert was incorrectly calling lengthOfNullTerminatedString
on the UChar in the assert, but this constructor is used for
byte sequences which are not null terminated.

BUG=615174
==========

to

==========
Expand WTF::StringView's API to be more like StringPiece.

StringView no longer owns the string passed into it, and can now wrap
a raw ptr to some characters.

This allows us to leverage the inline strlen optimization where the
compiler will embed the length of literal strings into the binary. It
also allows the deletion many overloaded methods that used to take
an LChar*, UChar* or String and can now just take a StringView instead.

For example the two constructors in TextRun are now a single one that
takes a StringView. This needed to be done in this patch to avoid
ambiguous constructors.

Future patches will replace CSSParserString with StringView, and also
vastly simplify the huge number of overloads on various methods. We'll
also expand the API surface of StringView to include the many useful
operations that StringPiece has.

This was originally committed as: 
https://crrev.com/330deea56e27bc760fa52101040a51428bb7f582 but was
reverted due an incorrect assert in the
StringView(const UChar*, unsigned length) constructor. The assert
was incorrectly calling lengthOfNullTerminatedString on the UChar
in the assert, but this constructor is used for byte sequences which
are not null terminated.

BUG=615174
==========

[esprehn, 2016-05-31 20:25:10]

The CQ bit was checked by esprehn@chromium.org

[esprehn, 2016-05-31 20:25:10]

The patchset sent to the CQ was uploaded after l-g-t-m from
haraken@chromium.org, yutak@chromium.org
Link to the patchset: https://codereview.chromium.org/2007103003/#ps240001
(title: "Remove bad assert.")

[commit-bot: I haz the power, 2016-05-31 20:25:35]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2007103003/240001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/2007103003/240001

[commit-bot: I haz the power, 2016-05-31 21:51:46]

Committed patchset #13 (id:240001)

[commit-bot: I haz the power, 2016-05-31 21:53:47]

Description was changed from

==========
Expand WTF::StringView's API to be more like StringPiece.

StringView no longer owns the string passed into it, and can now wrap
a raw ptr to some characters.

This allows us to leverage the inline strlen optimization where the
compiler will embed the length of literal strings into the binary. It
also allows the deletion many overloaded methods that used to take
an LChar*, UChar* or String and can now just take a StringView instead.

For example the two constructors in TextRun are now a single one that
takes a StringView. This needed to be done in this patch to avoid
ambiguous constructors.

Future patches will replace CSSParserString with StringView, and also
vastly simplify the huge number of overloads on various methods. We'll
also expand the API surface of StringView to include the many useful
operations that StringPiece has.

This was originally committed as: 
https://crrev.com/330deea56e27bc760fa52101040a51428bb7f582 but was
reverted due an incorrect assert in the
StringView(const UChar*, unsigned length) constructor. The assert
was incorrectly calling lengthOfNullTerminatedString on the UChar
in the assert, but this constructor is used for byte sequences which
are not null terminated.

BUG=615174
==========

to

==========
Expand WTF::StringView's API to be more like StringPiece.

StringView no longer owns the string passed into it, and can now wrap
a raw ptr to some characters.

This allows us to leverage the inline strlen optimization where the
compiler will embed the length of literal strings into the binary. It
also allows the deletion many overloaded methods that used to take
an LChar*, UChar* or String and can now just take a StringView instead.

For example the two constructors in TextRun are now a single one that
takes a StringView. This needed to be done in this patch to avoid
ambiguous constructors.

Future patches will replace CSSParserString with StringView, and also
vastly simplify the huge number of overloads on various methods. We'll
also expand the API surface of StringView to include the many useful
operations that StringPiece has.

This was originally committed as:
https://crrev.com/330deea56e27bc760fa52101040a51428bb7f582 but was
reverted due an incorrect assert in the
StringView(const UChar*, unsigned length) constructor. The assert
was incorrectly calling lengthOfNullTerminatedString on the UChar
in the assert, but this constructor is used for byte sequences which
are not null terminated.

BUG=615174

Committed: https://crrev.com/9b0aad1eca55ac75f437789514224e9b922fe514
Cr-Commit-Position: refs/heads/master@{#396942}
==========

[commit-bot: I haz the power, 2016-05-31 21:53:49]

Patchset 13 (id:??) landed as
https://crrev.com/9b0aad1eca55ac75f437789514224e9b922fe514
Cr-Commit-Position: refs/heads/master@{#396942}