Open Bug 1367105 Opened 2 years ago Updated 5 days ago
Sync irregexp with upstream
There are several stage 3 TC39 proposals regarding regexps in flight: 1. lookbehind (https://github.com/tc39/proposal-regexp-lookbehind) 2. Unicode groups (https://github.com/tc39/proposal-regexp-named-groups) 3. Unicode properties (https://github.com/tc39/proposal-regexp-unicode-property-escapes) 4. dotAll (https://github.com/tc39/proposal-regexp-dotall-flag) These are already implemented in V8, so we should take them.
http://searchfox.org/mozilla-central/source/js/src/tests/ecma_6/RegExp/unicode-ignoreCase.js needs much longer after updating to upstream irregexp, filed https://bugs.chromium.org/p/v8/issues/detail?id=6727 for further investigation.
(In reply to André Bargull [:anba] from comment #1) > http://searchfox.org/mozilla-central/source/js/src/tests/ecma_6/RegExp/ > unicode-ignoreCase.js needs much longer after updating to upstream irregexp, > filed https://bugs.chromium.org/p/v8/issues/detail?id=6727 for further > investigation. Does this know you have a patch for updating irregexp? If so, can you post it here, even though it's not ready to land because of the perf regression? Or did you just test the performance in v8 and expect the same regression to happen in SM?
(In reply to Till Schneidereit [:till] from comment #2) > Does this know you have a patch for updating irregexp? If so, can you post > it here, even though it's not ready to land because of the perf regression? > Or did you just test the performance in v8 and expect the same regression to > happen in SM? Yes, I have a very raw patch (or rather queue of patches) to sync with upstream. Some of the patches still need to be reordered, or in some cases later patches contain changes which actually belong to an earlier patch. There are lots of changes, simply because 1. Upstream has some methods in other files, so I had to reorder many methods/classes to match upstream, which makes it easier to compare differences between our version and upstream. 2. Our irregexp version was partially reformatted using the SpiderMonkey coding styles, which made it quite difficult to spot changes when comparing to upstream irregexp, so I had to change it back to the upstream formatting. I pushed the changes to try: https://hg.mozilla.org/try/pushloghtml?changeset=958c5b935c048c2ee59d608ae304def15804a976 Things still missing in those patches: 1. Support for the stage 3 proposals (it's probably cleaner to implement those changes in separate bugs) 2. Updates for NativeRegExpMacroAssembler (sstangl already volunteered to port any necessary assembler changes :-)
(In reply to André Bargull [:anba] from comment #3) > Things still missing in those patches: > 1. Support for the stage 3 proposals (it's probably cleaner to implement > those changes in separate bugs) Chrome 64 already enables all Stage 3 proposals by default, so maybe they are ready to be imported now.
André, sorry for not following up sooner, but can you update the patches to fix the -werr issue? Most of the new spec changes blocked by this have reached stage 4 today, so it'd be great if we could ship them soon-ish.
Upstream landed some bug-fixes and performance improvements we definitely want to take to avoid regressions compared to our current irregexp version. On top of that, upstream landed a few clean-ups which "nicely" conflict with the current patches [1,2,3] and also other internal changes like  which we probably should take, too, so it's easier for us to implement the stage 4 proposals. I did start updating the patches this week, but it's a cumbersome process because I effectively need to compare every single irregexp file with a diff-tool to see what needs to be updated in our local copy. :-/  https://github.com/v8/v8/commit/62f929ff4cf322bc05e3a384c4ad18005f50ebda  https://github.com/v8/v8/commit/447af335e044c92196de3c3ddf1059fad6901650  https://github.com/v8/v8/commit/ab43c76dde97188e79a6a1c5bb994407606521d2  https://github.com/v8/v8/commit/04f7d484db22b1526afa5414c06eda443c5b4fad
This issue blocks 4 RegExp features that ware already approved by TC39 and are now part of the ES2018 standard.
André, we have to get this done. Ashley's interested in finishing the work. Are the patches linked in comment 3 the latest version? Are those patches still a good starting point?
I have local (git) patches from this year April, which are probably a better starting point, except I don't know offhand in which state these patches are in. I'll try to look into them in the next week. (Keeping the NI for now so I don't forgot about this.)
My current patches, last updated in April.
Type: defect → enhancement
You need to log in before you can comment on or make changes to this bug.