mcs/class/System/System.Text.RegularExpressions/notes.txt

   1 TODO:
   2
   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.
  13
  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
  19   specification either.
  20
  21 * Octal/backreference parsing needs a big fix. The rules are ridiculously complex.
  22
  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.
  28
  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.
  33
  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.