…nstruct.

Be sure to keep track of named subpattern references as well as the
highes numbered subpattern reference encountered.

…ERT.

Also, keep track of which registers have been referenced by number.

…patterns referenced in the regex.

… register closure.

This required several things that may not have been necessary and will
have to be revisited.  First of all, for every register, we now create
two inner matchers: one that matches the contents of the register and
what follows the register, and one that only matches the contents of
the register.  Also, we now stop accumulating into STARTS-WITH once we
encounter a register or subpattern reference.

With this patch, subpattern references seem to work for the most part.
They do not yet work with repetitions.

At this point, one thing that doesn't work quite right is the
determination of register offsets for registers accessed indirectly by
subpattern references.  For example:

  (cl-ppcre:scan "(\\([^()]*((?1)\\)|\\)))" "((()))")

says that the second register is at position (3, 6), though it should
be (1, 6).  Fixing this will require binding a special variable from
subpattern reference closures that tells register closures not to
touch the register offsets.

…ctly from a subpattern reference.

With this patch, the following invocation:
  (cl-ppcre:scan "(\\([^()]*((?1)\\)|\\)))" "((()))")
gives the correct offset values for the second register as (1,6).

One problem that remains is the danger of infinite recursion during
backtracking.  The following invocation:
  (cl-ppcre:scan "(?1)(?2)(a|b|(?1))(c)" "acba")

causes a stack overflow because the second (?1) is called endlessly
during backtracking without the match position advancing through the
string.  Such behavior may be able to be remedied by having the
subpattern reference's closure keep track of where in *STRING* it has
been called before.

This is going to be reverted immediately, since apparently Perl isn't
smart enough to do this and will itself overflow the stack.

This reverts commit 69f0d7c.

1634 and 1635 currently don't work.

…trings in patterns containing subpattern references.

Current, the following tests fail: 1638, 1639, 1641, 1642, 1643, 1644,
1645, 1646.

… not called.

The NEXT-FN (or OTHER-FN) parameter is only called when the register's
inner matcher succeeds.  When the inner matcher failed,
INSIDE-SUBPATTERN-REFERENCE was not being unset, though it should have
been.

…n reference.

This patch fixes tests 1643-1646.

…PATTERN-REFS.

It's actually not clear that this is faster, though it probably is.

…les.

There is another way to go about this, but there's really no telling
which way would be faster.  The advantage to contructing two matchers
is that it only happens once and compilation time.

The optimization suggested there is trivial.

Perl does not allow whitespace around numbers/names in subpattern
references.

…he given name, as in Perl.

This currently doesn't work for forward references.  E.g.:

(let ((ppcre::*allow-named-registers* t))
  (ppcre:scan (ppcre:parse-string "(?&foo)(?<foo>f)(?<foo>o)") "ffo"))

returns NIL.

…es for special case.

The special case is where the forward reference refers to the
beginning of the constant end of string.  These tests currently fail.

The tests are now so ordered that every numbered subpattern reference
test is followed by a corresponding named subpattern reference test.

…es are present.

…ferences.

If the user has bound this variable to T, the simple tests will not
all pass.

…ern references.

These tests make sure that CL-PPCRE uses the correct named register
when multiple registers have the same name.

This question has been answered an implemented in a previous commit.

As with their offsets, determing the minimum lengths subpattern
references is only feasible for patterns that don't really need
subpattern references to begin with.

…REFERENCE.

…isters.

The perltestdata file produced by this updated perltest.pl only
reports results for registers that are actually contained in the
corresponding pattern.

… references.

These are not worth the time, especially considering that they're
trivially easy to simulate.

We know a named reg has been seen when one or more of the elements of
REG-NAMES is true.

Specifically, once we see a register, continue building the constant
string beginning unless the regex contains a subpattern reference.

The test numbers are no longer correct and are subject to change further.

…n references.

Instead, every time we descend into a register from a subpattern
reference, we first push a value onto a register-specific list and pop
it off once we return.  When STORE-END-OF-REG sees that there is a
value on the list, it knows we entered the register from a subpattern
reference and doesn't try to match the part of the regex following the
register.

It's hard to say whether this improves or degrades performance and
readability.  But it does seem simpler.

…ttern references.

These currently fail.

This enables correct matching for calls such as:

  (ppcre:scan "(?1)(o(?1)?)" "oo")

Add some comments, and rename a variable.

These were taken from PCRE's file testdata/testinput2 with slight
modifications.

These tests were taken from PCRE's testdata/testinput2 with slight
modifications.

These were taken from PCRE's testdata/testinput2 with slight modifications.

…ATTERN-REFERENCE.

(No periods, no capitalized sentences.)

… columns.

…RT-NAMED-SUBPATTERN-REF.

I believe this exhausts all possibilities that need to be covered.

…for.

Also, add a test for using subpattern references with the :FILTER
feature.

…referring to registers outside the referenced subpattern.

This currently fails.  When entering into a subpattern reference, Perl
only creates new registers for those capture groups located inside the
subpattern reference.  The capture groups outside the subpattern
reference retain their values.

…k-reference cooperation.

Instead of storing the beginning/end of register offsets directly in
the corresponding arrays, we will now store lists where the car of
each list is the offset.  The reason for this is that when we descend
into a subpattern reference, instead of making a new array where all
offsets are reset, we will push new offsets onto the front of the
lists corresponding only to those registers contained within the
register we're entering via the subpattern reference.  In other words,
we'll only be resetting certain registers.  This will fix tests 1783
and 1785.

Which registers contain which other registers will be computed during
regex compilation.

At this points, I had expected everything to work as well as with the
old model, but there are still many tests that are failing, so
apparently there are some bugs left to iron out.

… storage model's defects.

…rn reference.

This was causing many tests to fail with bizarre error messages.  It
wasn't caught using the old register offsets storage model since the
array the value was beging stored in was a temporary array to begin
with.

With this commit, the only tests run by RUN-ALL-TESTS that fail are
those that Perl itself gets wrong.

…STER.

It was missing the definition of regThree.

…TER.

The redundant code was moved into LABELS function definitions.

These are tests that even Perl gets wrong.

The numbers of registers nested within a register must be contiguous
with each other and with that of the parent register, so there's no
need to compute a list of subregisters--we just need to know how many
are nested within, and we can compute the rest therefrom.

Each fails for a different reason.  The first fails because it matches
where Perl does not.  (It's not clear whose bug this is.)  The second
fails because we're not waiting until the regex has finished compiling
before validating register names.

These are like the previous two tests added in the previous commit,
except they deal with "self-referential" backreferences rather than
forward backreferences.