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 * Improve the perl test suite. Run under MS runtime to generate checksums for
  24   each trial. Checksums should incorporate: all captures (index, length) for all
  25   groups; names of explicit capturing groups, and the numbers they map to. Any
  26   other state? RegexTrial.Execute() will then compare result and checksum.
  27
  28 * The pattern (?(1?)a|b). It should fail: Perl fails, the MS implementation
  29   fails, but I pass. The documentation says that the construct (?(X)...) can be
  30   processed in two ways. If X is a valid group number, or a valid group name,
  31   then the expression becomes a capture conditional - the (...) part is
  32   executed only if X has been captured. If X is not a group number or name, then
  33   it is treated as a positive lookahead., and (...) is only executed if the
  34   lookahead succeeds. My code does the latter, but on further investigation it
  35   appears that both Perl and MS fail to recognize an expression assertion if the
  36   first character of the assertion is a number - which instead suggests a
  37   capture conditional. The exception raised is something like "invalid group
  38   number". I get the feeling the my behaviour seems more correct, but it's not
  39   consistent with the other implementations, so it should probably be changed.