Fixed: Pipe in filter interpreted wrong when wildcards stripped away

This change has been suggested on the forum: https://adblockplus.org/forum/viewtopic.php?f=11&t=11935#p91135 This issue therefore also includes the ANSI range fix.

It doesn't break any of our unit tests and it achieves the expected results.

[Wladimir Palant, 2014-01-24 13:11:32]

http://codereview.adblockplus.org/4922123285954560/diff/5629499534213120/lib/...
File lib/filterClasses.js (right):

http://codereview.adblockplus.org/4922123285954560/diff/5629499534213120/lib/...
lib/filterClasses.js:514: source = source.replace(/\\\|$/, "$"); // process
anchor at expression end
This issue was introduced in the speedup here:
https://hg.adblockplus.org/adblockplus/rev/5161e5b4f7f8. Adding more branching
to this function likely eats away all the performance advantage gained. So I
guess a better solution is reverting the change there and processing
leading/trailing wildcards by regular expressions again - especially given that
regexp generation is happening delayed now and no longer plays a real role
performance-wise.

[Thomas Greiner, 2014-01-24 14:48:16]

Reverted it to the mentioned state with minor adaptions. Also reverted the 0x80
change or otherwise it would break a couple of unit tests.

http://codereview.adblockplus.org/4922123285954560/diff/5629499534213120/lib/...
File lib/filterClasses.js (right):

http://codereview.adblockplus.org/4922123285954560/diff/5629499534213120/lib/...
lib/filterClasses.js:514: source = source.replace(/\\\|$/, "$"); // process
anchor at expression end
On 2014/01/24 13:11:32, Wladimir Palant wrote:
> This issue was introduced in the speedup here:
> https://hg.adblockplus.org/adblockplus/rev/5161e5b4f7f8. Adding more branching
> to this function likely eats away all the performance advantage gained. So I
> guess a better solution is reverting the change there and processing
> leading/trailing wildcards by regular expressions again - especially given
that
> regexp generation is happening delayed now and no longer plays a real role
> performance-wise.

Done. If we still want to optimize the performance we could precompile the
regular expressions.

[Wladimir Palant, 2014-01-27 14:06:53]

LGTM whether or not you address the comment below.

http://codereview.adblockplus.org/4922123285954560/diff/5724160613416960/lib/...
File lib/filterClasses.js (right):

http://codereview.adblockplus.org/4922123285954560/diff/5724160613416960/lib/...
lib/filterClasses.js:498: .replace(/\\\^/g,
"(?:[\\x00-\\x24\\x26-\\x2C\\x2F\\x3A-\\x40\\x5B-\\x5E\\x60\\x7B-\\x80]|$)")
Nothing wrong with having \\x7F instead of \\x80 here, you were correct about
the ANSI range. Not that it really matters, character code 0x80 seems to be
unused in Unicode.