3 * Need to go through everything and square it with RightToLeft matching.
4 The support for this was built into an early version, and lots of things built
5 afterwards are not savvy about bi-directional matching. Things that spring to
6 mind: Regex match methods should start at 0 or text.Length depending on
7 direction. Do split and replace need changes? Match should be aware of its
8 direction (already applied some of this to NextMatch logic). The interpreter
9 needs to check left and right bounds. Anchoring and substring discovery need
10 to be reworked. RTL matches are going to have anchors on the right - ie $, \Z
11 and \z. This should be added to the anchor logic. QuickSearch needs to work in
12 reverse. There may be other stuff.... work through the code.
14 * Add ECMAScript support to the parser. For example, [.\w\s\d] map to ECMA
15 categories instead of canonical ones [DONE]. There's different behaviour on
16 backreference/octal disambiguation. Find out what the runtime behavioural
17 difference is for cyclic backreferences eg (?(1)abc\1) - this is only briefly
18 mentioned in the spec. I couldn't find much on this in the ECMAScript
21 * Octal/backreference parsing needs a big fix. The rules are ridiculously complex.
23 * Add a check in QuickSearch for single character substrings. This is likely to
24 be a common case. There's no need to go through a shift table. Also, have a
25 look at just computing a relevant subset of the shift table and using an
26 (offset, size) pair to help test inclusion. Characters not in the table get
27 the default len + 1 shift.
29 * Improve the perl test suite. Run under MS runtime to generate checksums for
30 each trial. Checksums should incorporate: all captures (index, length) for all
31 groups; names of explicit capturing groups, and the numbers they map to. Any
32 other state? RegexTrial.Execute() will then compare result and checksum.
34 * The pattern (?(1?)a|b). It should fail: Perl fails, the MS implementation
35 fails, but I pass. The documentation says that the construct (?(X)...) can be
36 processed in two ways. If X is a valid group number, or a valid group name,
37 then the expression becomes a capture conditional - the (...) part is
38 executed only if X has been captured. If X is not a group number or name, then
39 it is treated as a positive lookahead., and (...) is only executed if the
40 lookahead succeeds. My code does the latter, but on further investigation it
41 appears that both Perl and MS fail to recognize an expression assertion if the
42 first character of the assertion is a number - which instead suggests a
43 capture conditional. The exception raised is something like "invalid group
44 number". I get the feeling the my behaviour seems more correct, but it's not
45 consistent with the other implementations, so it should probably be changed.