Use StringView for equalIgnoringCase.

Use StringView for equalIgnoringCase.

This lets us merge the code paths and simplifies the code a bunch.

In doing this I removed the ASCII fast path that was in the
equalsIgnoringCase(const StringImpl*, const LChar*) function, though
curiously it wasn't in the (const UChar*, const LChar*) one, but that
function is also used a lot less often. Lets try removing this ancient
fast path for now (from 2006 with no comments about why it exists [1])
and instead opt for simpler code.

For comparing LChar strings the new path should be just as fast if not
faster. For comparing LChar to UChar strings we end up doing a foldCase
call which will be slower, but we should see how bad it is first.

Long term almost all callers of equalIgnoringCase need to switch to
equalIgnoringASCIICase anyway since that's what the specs require
(and what Webkit does now), which will put this fast path back in
place. We can also add the fast path back in the (LChar, UChar) path
if needed.

Switching all of the callers over to the new StringView version of
equalIgnoringCase also exposed that the CSP parsing logic was
accidentally using the function incorrectly and doing prefix matches
instead of actually comparing to the expected values as described in
issue 634217. This patches fixes that mistake.

[1] https://chromium.googlesource.com/chromium/src/+/6f022a05a21fc5ed091d7bcb6b81104ea2afdf8e

BUG=615174, 634217
Committed: https://crrev.com/9a8e5154f97acb2d9ccdee61e464e0d2b33b100e
Cr-Commit-Position: refs/heads/master@{#409987}

[esprehn, 2016-07-15 00:41:05]

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

[commit-bot: I haz the power, 2016-07-15 00:41:49]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[esprehn, 2016-07-15 00:52:47]

Description was changed from

==========
Use StringView for equalIgnoringCase.

BUG=2146163003
==========

to

==========
Use StringView for equalIgnoringCase.

This lets us merge the code paths and simplifies the code a bunch.

In doing this I removed the ASCII fast path that was in the
equalsIgnoringCase(const StringImpl*, const LChar*) function, though
curiously it wasn't in the (const UChar*, const LChar*) one, but that
function is also used a lot less often. Lets try removing this ancient
fast path for now (from 2006 with no comments about why it exists [1])
and instead opt for simpler code.

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

[esprehn, 2016-07-15 00:53:04]

Description was changed from

==========
Use StringView for equalIgnoringCase.

This lets us merge the code paths and simplifies the code a bunch.

In doing this I removed the ASCII fast path that was in the
equalsIgnoringCase(const StringImpl*, const LChar*) function, though
curiously it wasn't in the (const UChar*, const LChar*) one, but that
function is also used a lot less often. Lets try removing this ancient
fast path for now (from 2006 with no comments about why it exists [1])
and instead opt for simpler code.

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

to

==========
Use StringView for equalIgnoringCase.

This lets us merge the code paths and simplifies the code a bunch.

In doing this I removed the ASCII fast path that was in the
equalsIgnoringCase(const StringImpl*, const LChar*) function, though
curiously it wasn't in the (const UChar*, const LChar*) one, but that
function is also used a lot less often. Lets try removing this ancient
fast path for now (from 2006 with no comments about why it exists [1])
and instead opt for simpler code.

[1]
https://chromium.googlesource.com/chromium/src/+/6f022a05a21fc5ed091d7bcb6b81...


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

[esprehn, 2016-07-15 00:54:10]

Description was changed from

==========
Use StringView for equalIgnoringCase.

This lets us merge the code paths and simplifies the code a bunch.

In doing this I removed the ASCII fast path that was in the
equalsIgnoringCase(const StringImpl*, const LChar*) function, though
curiously it wasn't in the (const UChar*, const LChar*) one, but that
function is also used a lot less often. Lets try removing this ancient
fast path for now (from 2006 with no comments about why it exists [1])
and instead opt for simpler code.

[1]
https://chromium.googlesource.com/chromium/src/+/6f022a05a21fc5ed091d7bcb6b81...


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

to

==========
Use StringView for equalIgnoringCase.

This lets us merge the code paths and simplifies the code a bunch.

In doing this I removed the ASCII fast path that was in the
equalsIgnoringCase(const StringImpl*, const LChar*) function, though
curiously it wasn't in the (const UChar*, const LChar*) one, but that
function is also used a lot less often. Lets try removing this ancient
fast path for now (from 2006 with no comments about why it exists [1])
and instead opt for simpler code.

Long term almost all callers of equalIgnoringCase need to switch to
equalIgnoringASCIICase anyway since that's what the specs require
(and what Webkit does now), which will put this fast path back in
place.

[1]
https://chromium.googlesource.com/chromium/src/+/6f022a05a21fc5ed091d7bcb6b81...


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

[commit-bot: I haz the power, 2016-07-15 02:13:01]

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

[commit-bot: I haz the power, 2016-07-15 02:13:02]

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

[esprehn, 2016-07-15 03:00:00]

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

[commit-bot: I haz the power, 2016-07-15 03:00:16]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-15 04:04:20]

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

[commit-bot: I haz the power, 2016-07-15 04:04:22]

Dry run: Try jobs failed on following builders:
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[esprehn, 2016-07-15 04:14:47]

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

[commit-bot: I haz the power, 2016-07-15 04:14:58]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-15 05:43:32]

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

[commit-bot: I haz the power, 2016-07-15 05:43:33]

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

[esprehn, 2016-07-15 20:32:43]

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

[commit-bot: I haz the power, 2016-07-15 20:33:44]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-15 22:00:58]

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

[commit-bot: I haz the power, 2016-07-15 22:00:59]

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

[esprehn, 2016-08-04 05:42:26]

Description was changed from

==========
Use StringView for equalIgnoringCase.

This lets us merge the code paths and simplifies the code a bunch.

In doing this I removed the ASCII fast path that was in the
equalsIgnoringCase(const StringImpl*, const LChar*) function, though
curiously it wasn't in the (const UChar*, const LChar*) one, but that
function is also used a lot less often. Lets try removing this ancient
fast path for now (from 2006 with no comments about why it exists [1])
and instead opt for simpler code.

Long term almost all callers of equalIgnoringCase need to switch to
equalIgnoringASCIICase anyway since that's what the specs require
(and what Webkit does now), which will put this fast path back in
place.

[1]
https://chromium.googlesource.com/chromium/src/+/6f022a05a21fc5ed091d7bcb6b81...


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

to

==========
Use StringView for equalIgnoringCase.

This lets us merge the code paths and simplifies the code a bunch.

In doing this I removed the ASCII fast path that was in the
equalsIgnoringCase(const StringImpl*, const LChar*) function, though
curiously it wasn't in the (const UChar*, const LChar*) one, but that
function is also used a lot less often. Lets try removing this ancient
fast path for now (from 2006 with no comments about why it exists [1])
and instead opt for simpler code.

Long term almost all callers of equalIgnoringCase need to switch to
equalIgnoringASCIICase anyway since that's what the specs require
(and what Webkit does now), which will put this fast path back in
place.

[1]
https://chromium.googlesource.com/chromium/src/+/6f022a05a21fc5ed091d7bcb6b81...


BUG=615174, 634217
==========

[esprehn, 2016-08-04 06:08:10]

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

[commit-bot: I haz the power, 2016-08-04 06:08:31]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-04 07:43:00]

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

[commit-bot: I haz the power, 2016-08-04 07:43:01]

Dry run: This issue passed the CQ dry run.

[esprehn, 2016-08-04 08:41:09]

Description was changed from

==========
Use StringView for equalIgnoringCase.

This lets us merge the code paths and simplifies the code a bunch.

In doing this I removed the ASCII fast path that was in the
equalsIgnoringCase(const StringImpl*, const LChar*) function, though
curiously it wasn't in the (const UChar*, const LChar*) one, but that
function is also used a lot less often. Lets try removing this ancient
fast path for now (from 2006 with no comments about why it exists [1])
and instead opt for simpler code.

Long term almost all callers of equalIgnoringCase need to switch to
equalIgnoringASCIICase anyway since that's what the specs require
(and what Webkit does now), which will put this fast path back in
place.

[1]
https://chromium.googlesource.com/chromium/src/+/6f022a05a21fc5ed091d7bcb6b81...


BUG=615174, 634217
==========

to

==========
Use StringView for equalIgnoringCase.

This lets us merge the code paths and simplifies the code a bunch.

In doing this I removed the ASCII fast path that was in the
equalsIgnoringCase(const StringImpl*, const LChar*) function, though
curiously it wasn't in the (const UChar*, const LChar*) one, but that
function is also used a lot less often. Lets try removing this ancient
fast path for now (from 2006 with no comments about why it exists [1])
and instead opt for simpler code. The new path just ends up comparing
values from the case folding table so it should be just as fast if not
faster.

Long term almost all callers of equalIgnoringCase need to switch to
equalIgnoringASCIICase anyway since that's what the specs require
(and what Webkit does now), which will put this fast path back in
place.

Switching all of the callers over to the new StringView version of
equalIgnoringCase also exposed that the CSP parsing logic was
accidentally using the function incorrectly and doing prefix matches
instead of actually comparing to the expected values as described in
issue 634217. This patches fixes that mistake.

[1]
https://chromium.googlesource.com/chromium/src/+/6f022a05a21fc5ed091d7bcb6b81...

BUG=615174, 634217
==========

[esprehn, 2016-08-04 08:43:05]

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

[esprehn, 2016-08-04 08:43:06]

https://codereview.chromium.org/2148423003/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/wtf/text/StringImpl.cpp (left):

https://codereview.chromium.org/2148423003/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/wtf/text/StringImpl.cpp:2103: equal = equal &&
(toASCIILower(ac) == toASCIILower(bc));
We lose this fancy ASCII path and end up doing:

    while (length--) {
        if (StringImpl::latin1CaseFoldTable[*a++] !=
StringImpl::latin1CaseFoldTable[*b++])
            return false;
    }

https://codereview.chromium.org/2148423003/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/wtf/text/StringImpl.cpp:2130: equal = equal &&
(foldCase(as[i]) == foldCase(b[i]));
We also lose this ASCII fast path and end up doing:

    while (length--) {
        if (foldCase(*a++) != StringImpl::latin1CaseFoldTable[*b++])
            return false;
    }

which is probably slower since we need to call foldCase. If this shows up in
benchmarks we can add this ASCII fast path back to
equalIgnoringCase(const UChar* a, const LChar* b, unsigned length)

but I'd like to just remove it for now since the (UChar*, LChar*) version of
this never had this fast path. The fast path dates to an ancient patch from
2006:
https://chromium.googlesource.com/chromium/src/+/6f022a05a21fc5ed091d7bcb6b81...

but there's nothing cited in it about why darin added all of these fast paths
all over. It's possible calling ICU is slow, but lets find out.

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

https://codereview.chromium.org/2148423003/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/wtf/text/StringView.h:42: StringView(const
StringImpl*);
const StringImpl* is kind of silly since they're immutable, at one point people
tried using it to signal that the ref count won't be modified, but the
RefCounted's ref() and deref() are actually const since a ref count is logically
const and RefPtr<const Foo> is supposed to work (base does this too) so it
doesn't really matter anymore.

Some callers of equalsIgnoringCase have a const StringImpl, so we add it here
too which matches the old signature of equalIgnoringCase.

[esprehn, 2016-08-04 08:45:15]

Description was changed from

==========
Use StringView for equalIgnoringCase.

This lets us merge the code paths and simplifies the code a bunch.

In doing this I removed the ASCII fast path that was in the
equalsIgnoringCase(const StringImpl*, const LChar*) function, though
curiously it wasn't in the (const UChar*, const LChar*) one, but that
function is also used a lot less often. Lets try removing this ancient
fast path for now (from 2006 with no comments about why it exists [1])
and instead opt for simpler code. The new path just ends up comparing
values from the case folding table so it should be just as fast if not
faster.

Long term almost all callers of equalIgnoringCase need to switch to
equalIgnoringASCIICase anyway since that's what the specs require
(and what Webkit does now), which will put this fast path back in
place.

Switching all of the callers over to the new StringView version of
equalIgnoringCase also exposed that the CSP parsing logic was
accidentally using the function incorrectly and doing prefix matches
instead of actually comparing to the expected values as described in
issue 634217. This patches fixes that mistake.

[1]
https://chromium.googlesource.com/chromium/src/+/6f022a05a21fc5ed091d7bcb6b81...

BUG=615174, 634217
==========

to

==========
Use StringView for equalIgnoringCase.

This lets us merge the code paths and simplifies the code a bunch.

In doing this I removed the ASCII fast path that was in the
equalsIgnoringCase(const StringImpl*, const LChar*) function, though
curiously it wasn't in the (const UChar*, const LChar*) one, but that
function is also used a lot less often. Lets try removing this ancient
fast path for now (from 2006 with no comments about why it exists [1])
and instead opt for simpler code.

For comparing LChar strings the new path should be just as fast if not
faster. For comparing LChar to UChar strings we end up doing a foldCase
call which will be slower, but we should see how bad it is first.

Long term almost all callers of equalIgnoringCase need to switch to
equalIgnoringASCIICase anyway since that's what the specs require
(and what Webkit does now), which will put this fast path back in
place. We can also add the fast path back in the (LChar, UChar) path
if needed.

Switching all of the callers over to the new StringView version of
equalIgnoringCase also exposed that the CSP parsing logic was
accidentally using the function incorrectly and doing prefix matches
instead of actually comparing to the expected values as described in
issue 634217. This patches fixes that mistake.

[1]
https://chromium.googlesource.com/chromium/src/+/6f022a05a21fc5ed091d7bcb6b81...

BUG=615174, 634217
==========

[haraken, 2016-08-04 09:05:28]

LGTM

https://codereview.chromium.org/2148423003/diff/80001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/html/parser/HTMLTreeBuilderSimulator.cpp
(right):

https://codereview.chromium.org/2148423003/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/html/parser/HTMLTreeBuilderSimulator.cpp:95:
return equalIgnoringCaseAndNullity(*token.data().impl(),
*SVGNames::foreignObjectTag.localName().impl());

Honestly speaking, I'm not sure how much it makes sense to have the micro
optimization. I might prefer just removing equalIgnoringCaseAndNullity.

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

https://codereview.chromium.org/2148423003/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/wtf/text/StringView.cpp:68: {

Can we add:

  DCHECK(!a.isNull());
  DCHECK(!b.isNull());

?

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

https://codereview.chromium.org/2148423003/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/wtf/text/StringView.h:42: StringView(const
StringImpl*);

Add explicit.

[Mike West, 2016-08-04 11:20:40]

Whoops! Thank for for catching this error, esprehn@. The fix LGTM.

[esprehn, 2016-08-04 18:30:08]

https://codereview.chromium.org/2148423003/diff/80001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/html/parser/HTMLTreeBuilderSimulator.cpp
(right):

https://codereview.chromium.org/2148423003/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/html/parser/HTMLTreeBuilderSimulator.cpp:95:
return equalIgnoringCaseAndNullity(*token.data().impl(),
*SVGNames::foreignObjectTag.localName().impl());
On 2016/08/04 at 09:05:28, haraken wrote:
> Honestly speaking, I'm not sure how much it makes sense to have the micro
optimization. I might prefer just removing equalIgnoringCaseAndNullity.

I can remove the optimization here, but we still want the function since it has
different semantics, like:

https://cs.chromium.org/chromium/src/third_party/WebKit/Source/wtf/text/WTFSt...

which is used by various code.

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

https://codereview.chromium.org/2148423003/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/wtf/text/StringView.cpp:68: {
On 2016/08/04 at 09:05:28, haraken wrote:
> Can we add:
> 
>   DCHECK(!a.isNull());
>   DCHECK(!b.isNull());
> 
> ?

No since the semantics are that you still allow null strings, you just ignore
it. So you treat null strings as having a zero length instead of being special.

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

https://codereview.chromium.org/2148423003/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/wtf/text/StringView.h:42: StringView(const
StringImpl*);
On 2016/08/04 at 09:05:28, haraken wrote:
> Add explicit.

It's implicit on purpose, otherwise doing

StringImpl* string;
if (equalIgnoringCase("example", string))

won't work.

[esprehn, 2016-08-04 21:57:19]

https://codereview.chromium.org/2148423003/diff/80001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/html/parser/HTMLTreeBuilderSimulator.cpp
(right):

https://codereview.chromium.org/2148423003/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/html/parser/HTMLTreeBuilderSimulator.cpp:95:
return equalIgnoringCaseAndNullity(*token.data().impl(),
*SVGNames::foreignObjectTag.localName().impl());
I removed this optimization but left the one in the hash table.

https://codereview.chromium.org/2148423003/diff/100001/third_party/WebKit/Sou...
File third_party/WebKit/Source/wtf/text/StringImpl.cpp (right):

https://codereview.chromium.org/2148423003/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/wtf/text/StringImpl.cpp:1144: if (a == b)
I added this optimization back for both UChar and LChar.

[esprehn, 2016-08-04 21:57:25]

The CQ bit was checked by esprehn@chromium.org

[esprehn, 2016-08-04 21:57:25]

The patchset sent to the CQ was uploaded after l-g-t-m from
haraken@chromium.org, mkwst@chromium.org
Link to the patchset: https://codereview.chromium.org/2148423003/#ps100001
(title: "Add back ptr compare step.")

[commit-bot: I haz the power, 2016-08-04 21:58:05]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-04 22:10:30]

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

[commit-bot: I haz the power, 2016-08-04 22:10:31]

Try jobs failed on following builders:
  chromeos_amd64-generic_chromium_compile_only_ng on
master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_amd64-...)
  linux_chromium_chromeos_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[esprehn, 2016-08-04 22:39:37]

The CQ bit was checked by esprehn@chromium.org

[esprehn, 2016-08-04 22:39:37]

The patchset sent to the CQ was uploaded after l-g-t-m from
haraken@chromium.org, mkwst@chromium.org
Link to the patchset: https://codereview.chromium.org/2148423003/#ps120001
(title: "DCHECK is silly.")

[commit-bot: I haz the power, 2016-08-04 22:40:05]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-04 23:56:48]

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

[commit-bot: I haz the power, 2016-08-04 23:56:49]

Try jobs failed on following builders:
  linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)

[esprehn, 2016-08-05 00:18:33]

The CQ bit was checked by esprehn@chromium.org

[commit-bot: I haz the power, 2016-08-05 00:19:07]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-05 04:01:26]

Committed patchset #7 (id:120001)

[commit-bot: I haz the power, 2016-08-05 04:03:32]

Description was changed from

==========
Use StringView for equalIgnoringCase.

This lets us merge the code paths and simplifies the code a bunch.

In doing this I removed the ASCII fast path that was in the
equalsIgnoringCase(const StringImpl*, const LChar*) function, though
curiously it wasn't in the (const UChar*, const LChar*) one, but that
function is also used a lot less often. Lets try removing this ancient
fast path for now (from 2006 with no comments about why it exists [1])
and instead opt for simpler code.

For comparing LChar strings the new path should be just as fast if not
faster. For comparing LChar to UChar strings we end up doing a foldCase
call which will be slower, but we should see how bad it is first.

Long term almost all callers of equalIgnoringCase need to switch to
equalIgnoringASCIICase anyway since that's what the specs require
(and what Webkit does now), which will put this fast path back in
place. We can also add the fast path back in the (LChar, UChar) path
if needed.

Switching all of the callers over to the new StringView version of
equalIgnoringCase also exposed that the CSP parsing logic was
accidentally using the function incorrectly and doing prefix matches
instead of actually comparing to the expected values as described in
issue 634217. This patches fixes that mistake.

[1]
https://chromium.googlesource.com/chromium/src/+/6f022a05a21fc5ed091d7bcb6b81...

BUG=615174, 634217
==========

to

==========
Use StringView for equalIgnoringCase.

This lets us merge the code paths and simplifies the code a bunch.

In doing this I removed the ASCII fast path that was in the
equalsIgnoringCase(const StringImpl*, const LChar*) function, though
curiously it wasn't in the (const UChar*, const LChar*) one, but that
function is also used a lot less often. Lets try removing this ancient
fast path for now (from 2006 with no comments about why it exists [1])
and instead opt for simpler code.

For comparing LChar strings the new path should be just as fast if not
faster. For comparing LChar to UChar strings we end up doing a foldCase
call which will be slower, but we should see how bad it is first.

Long term almost all callers of equalIgnoringCase need to switch to
equalIgnoringASCIICase anyway since that's what the specs require
(and what Webkit does now), which will put this fast path back in
place. We can also add the fast path back in the (LChar, UChar) path
if needed.

Switching all of the callers over to the new StringView version of
equalIgnoringCase also exposed that the CSP parsing logic was
accidentally using the function incorrectly and doing prefix matches
instead of actually comparing to the expected values as described in
issue 634217. This patches fixes that mistake.

[1]
https://chromium.googlesource.com/chromium/src/+/6f022a05a21fc5ed091d7bcb6b81...

BUG=615174, 634217

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

[commit-bot: I haz the power, 2016-08-05 04:03:33]

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