[regexp] extend property classes by unicode blocks.

[regexp] extend property classes by unicode blocks.

R=littledan@chromium.org
BUG=v8:4810
LOG=N

Committed: https://crrev.com/5be770b59fe6c8a7c7168166dd26d6c057d3fd87
Cr-Commit-Position: refs/heads/master@{#34702}

[Dan Ehrenberg, 2016-03-10 18:43:20]

https://codereview.chromium.org/1780183002/diff/20001/src/regexp/regexp-parse...
File src/regexp/regexp-parser.cc (right):

https://codereview.chromium.org/1780183002/diff/20001/src/regexp/regexp-parse...
src/regexp/regexp-parser.cc:903: // to settle.
I don't like this mechanism, of letting them overlap and then also allowing
disambiguation! If there's a block by a particular name in one Unicode version,
and then a script is added later by the same name, then you'll get different
results. I think Brian Terlson proposed making "In" for blocks mandatory and not
exist ever for scripts. What if we either did that, or Is/In mandatory?

[Yang, 2016-03-10 19:21:11]

On 2016/03/10 18:43:20, Dan Ehrenberg wrote:
>
https://codereview.chromium.org/1780183002/diff/20001/src/regexp/regexp-parse...
> File src/regexp/regexp-parser.cc (right):
> 
>
https://codereview.chromium.org/1780183002/diff/20001/src/regexp/regexp-parse...
> src/regexp/regexp-parser.cc:903: // to settle.
> I don't like this mechanism, of letting them overlap and then also allowing
> disambiguation! If there's a block by a particular name in one Unicode
version,
> and then a script is added later by the same name, then you'll get different
> results. I think Brian Terlson proposed making "In" for blocks mandatory and
not
> exist ever for scripts. What if we either did that, or Is/In mandatory?

There is not much to be found here: https://github.com/goyakin/es-regexp
So I just followed examples in other regexp implementations, all the while
waiting for something to materialize. Is there any draft to go by at this point?

I changed so that scripts do not need a prefix, and blocks require the
"In"-prefix.

[Yang, 2016-03-10 21:23:07]

On 2016/03/10 19:21:11, Yang wrote:
> On 2016/03/10 18:43:20, Dan Ehrenberg wrote:
> >
>
https://codereview.chromium.org/1780183002/diff/20001/src/regexp/regexp-parse...
> > File src/regexp/regexp-parser.cc (right):
> > 
> >
>
https://codereview.chromium.org/1780183002/diff/20001/src/regexp/regexp-parse...
> > src/regexp/regexp-parser.cc:903: // to settle.
> > I don't like this mechanism, of letting them overlap and then also allowing
> > disambiguation! If there's a block by a particular name in one Unicode
> version,
> > and then a script is added later by the same name, then you'll get different
> > results. I think Brian Terlson proposed making "In" for blocks mandatory and
> not
> > exist ever for scripts. What if we either did that, or Is/In mandatory?
> 
> There is not much to be found here: https://github.com/goyakin/es-regexp
> So I just followed examples in other regexp implementations, all the while
> waiting for something to materialize. Is there any draft to go by at this
point?
> 
> I changed so that scripts do not need a prefix, and blocks require the
> "In"-prefix.

Do we want to land this now or are you suggesting to wait until there is a
verdict on the prefixes?

[Dan Ehrenberg, 2016-03-10 21:55:28]

On 2016/03/10 at 21:23:07, yangguo wrote:
> On 2016/03/10 19:21:11, Yang wrote:
> > On 2016/03/10 18:43:20, Dan Ehrenberg wrote:
> > >
> >
https://codereview.chromium.org/1780183002/diff/20001/src/regexp/regexp-parse...
> > > File src/regexp/regexp-parser.cc (right):
> > > 
> > >
> >
https://codereview.chromium.org/1780183002/diff/20001/src/regexp/regexp-parse...
> > > src/regexp/regexp-parser.cc:903: // to settle.
> > > I don't like this mechanism, of letting them overlap and then also
allowing
> > > disambiguation! If there's a block by a particular name in one Unicode
> > version,
> > > and then a script is added later by the same name, then you'll get
different
> > > results. I think Brian Terlson proposed making "In" for blocks mandatory
and
> > not
> > > exist ever for scripts. What if we either did that, or Is/In mandatory?
> > 
> > There is not much to be found here: https://github.com/goyakin/es-regexp
> > So I just followed examples in other regexp implementations, all the while
> > waiting for something to materialize. Is there any draft to go by at this
point?
> > 
> > I changed so that scripts do not need a prefix, and blocks require the
> > "In"-prefix.
> 
> Do we want to land this now or are you suggesting to wait until there is a
verdict on the prefixes?

Yes, let's wait for some kind of resolution here. This is staged, so I think we
should hold it to a slightly higher standard.

[Yang, 2016-03-11 03:17:41]

On 2016/03/10 21:55:28, Dan Ehrenberg wrote:
> On 2016/03/10 at 21:23:07, yangguo wrote:
> > On 2016/03/10 19:21:11, Yang wrote:
> > > On 2016/03/10 18:43:20, Dan Ehrenberg wrote:
> > > >
> > >
>
https://codereview.chromium.org/1780183002/diff/20001/src/regexp/regexp-parse...
> > > > File src/regexp/regexp-parser.cc (right):
> > > > 
> > > >
> > >
>
https://codereview.chromium.org/1780183002/diff/20001/src/regexp/regexp-parse...
> > > > src/regexp/regexp-parser.cc:903: // to settle.
> > > > I don't like this mechanism, of letting them overlap and then also
> allowing
> > > > disambiguation! If there's a block by a particular name in one Unicode
> > > version,
> > > > and then a script is added later by the same name, then you'll get
> different
> > > > results. I think Brian Terlson proposed making "In" for blocks mandatory
> and
> > > not
> > > > exist ever for scripts. What if we either did that, or Is/In mandatory?
> > > 
> > > There is not much to be found here: https://github.com/goyakin/es-regexp
> > > So I just followed examples in other regexp implementations, all the while
> > > waiting for something to materialize. Is there any draft to go by at this
> point?
> > > 
> > > I changed so that scripts do not need a prefix, and blocks require the
> > > "In"-prefix.
> > 
> > Do we want to land this now or are you suggesting to wait until there is a
> verdict on the prefixes?
> 
> Yes, let's wait for some kind of resolution here. This is staged, so I think
we
> should hold it to a slightly higher standard.

well no, this is not staged yet.

[Dan Ehrenberg, 2016-03-11 03:40:42]

lgtm

Oh my mistake, fine to submit, code looks good.

[Yang, 2016-03-11 06:55:20]

The CQ bit was checked by yangguo@chromium.org

[Yang, 2016-03-11 06:55:20]

The patchset sent to the CQ was uploaded after l-g-t-m from
littledan@chromium.org
Link to the patchset: https://codereview.chromium.org/1780183002/#ps60001
(title: "rebase")

[commit-bot: I haz the power, 2016-03-11 06:55:27]

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

[commit-bot: I haz the power, 2016-03-11 07:18:44]

Committed patchset #4 (id:60001)

[commit-bot: I haz the power, 2016-03-11 07:20:18]

Description was changed from

==========
[regexp] extend property classes by unicode blocks.

R=littledan@chromium.org
BUG=v8:4810
LOG=N
==========

to

==========
[regexp] extend property classes by unicode blocks.

R=littledan@chromium.org
BUG=v8:4810
LOG=N

Committed: https://crrev.com/5be770b59fe6c8a7c7168166dd26d6c057d3fd87
Cr-Commit-Position: refs/heads/master@{#34702}
==========

[commit-bot: I haz the power, 2016-03-11 07:20:19]

Patchset 4 (id:??) landed as
https://crrev.com/5be770b59fe6c8a7c7168166dd26d6c057d3fd87
Cr-Commit-Position: refs/heads/master@{#34702}