TRANSLATE-SEQ wasn't correctly accounting for submatches. The same bug occurred in a parallel position in TRANSLATE-CHOICE; when I fixed it there, I neglected to fix TRANSLATE-SEQ as well. Olin
This commit is contained in:
parent
f8975842de
commit
de5a415580
|
@ -39,6 +39,11 @@
|
|||
;;;
|
||||
;;; - paren count in the returned string.
|
||||
;;;
|
||||
;;; [This is a newer description; is it correct?]
|
||||
;;; - A vector mapping submatches (vector index 0 is submatch 1)
|
||||
;;; to the paren for that submatch (the first paren is paren #1).
|
||||
;;;
|
||||
;;; [This is my original description.]
|
||||
;;; - Vector of parens numbers used for submatching. The first paren is
|
||||
;;; numbered 1. #F means a dead submatch -- one we can tell statically
|
||||
;;; will never match anything.
|
||||
|
@ -199,7 +204,7 @@
|
|||
(values (string-append s1 s)
|
||||
2
|
||||
(+ pcount1 pcount)
|
||||
(vector-append (mapv (lambda (sm) (+ sm prev-smcount))
|
||||
(vector-append (mapv (lambda (p) (and p (+ p prev-pcount)))
|
||||
submatches1)
|
||||
submatches))))))
|
||||
|
||||
|
|
Loading…
Reference in New Issue