Pathanme translation bugs when TO contains complex patterns

[Richard M Kreuter]

(Apologies for this two-fer, but inspecting one bug uncovered the second, and they touch the same function.)

Problems:

1. Pathname translation doesn't perform lettercase translation correctly when the TO pathname's wildcard field is a complex pattern and the portions of FROM pathname are in a different lettercase than the non-wild portions of the TO pathname's wildcard field. (This can only be seen when translating logical pathnames to physical pathnames, as that's the only circumstance where SBCL tries to do lettercase translation.)

--
$ sh ./run-sbcl.sh --no-userinit --no-sysinit
(running SBCL from: .)
This is SBCL 1.3.2.69-aff4a0f, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
* (setf (logical-pathname-translations "foo") ()) ; establish the LPN host

NIL

* (translate-pathname "foo:a" "foo:*" "/*") ; NAME is :WILD, i.e., not complex

#P"/a"
* (translate-pathname "foo:ab" "foo:a*" "/z*") ; NAME is a #<PATTERN "a" :MULTI-CHAR-WILD>

#P"/zB"

* (translate-pathname "foo:ab;" "foo:a*;" "/z*/") ; DIRECTORY contains a PATTERN

#P"/zB/"

* (translate-pathname #p"foo:ab" #p"foo:a*" #p"/X*") ; NAME is a pattern

#P"/xb"

--

I expected the portions of SOURCE that matched wild syntax in FROM to be downcased in the result *and* alpha-chars in the pathname designated by TO to make it through translation verbatim.

2. When the field in TO corresponding to a wild field in FROM is a complex pattern prefixed by a constant string and the portion of SOURCE matching the wild field in FROM is also a complex pattern, the result of the translation contains the prefix twice:

--
(translate-pathname "a*" "*" "x*")

#P"xa*x"
--

I expected #P"xa*".

It looks like the culprit for these two cases is SB-IMPL::SUBSTITUTE-INTO in src/code/target-pathname.lisp. In short, the maybe-diddling ought to happen once per portion of the source to be substituted into the result, and the loop should clear the STRINGS accumulator when concatenating a piece. The attached patch achieves the desired effects for the above cases.

Other things requested in the bug reporting guidelines:

--
$ uname -a
Darwin m5.localdomain 14.5.0 Darwin Kernel Version 14.5.0: Wed Jul 29 02:26:53 PDT 2015; root:xnu-2782.40.9~1/RELEASE_X86_64 x86_64

* *features*

(:64-BIT :64-BIT-REGISTERS :ALIEN-CALLBACKS :ANSI-CL :ASH-RIGHT-VOPS :BSD
 :C-STACK-IS-CONTROL-STACK :COMMON-LISP :COMPARE-AND-SWAP-VOPS
 :COMPLEX-FLOAT-VOPS :CYCLE-COUNTER :DARWIN :DARWIN9-OR-BETTER :FLOAT-EQL-VOPS
 :FP-AND-PC-STANDARD-SAVE :GENCGC :IEEE-FLOATING-POINT :INLINE-CONSTANTS
 :INODE64 :INTEGER-EQL-VOP :INTERLEAVED-RAW-SLOTS :LINKAGE-TABLE :LITTLE-ENDIAN
 :MACH-EXCEPTION-HANDLER :MACH-O :MEMORY-BARRIER-VOPS :MULTIPLY-HIGH-VOPS
 :OS-PROVIDES-BLKSIZE-T :OS-PROVIDES-DLADDR :OS-PROVIDES-DLOPEN
 :OS-PROVIDES-PUTWC :OS-PROVIDES-SUSECONDS-T :PACKAGE-LOCAL-NICKNAMES
 :PRECISE-ARG-COUNT-ERROR :RAW-INSTANCE-INIT-VOPS :SB-DOC :SB-EVAL :SB-LDB
 :SB-PACKAGE-LOCKS :SB-SIMD-PACK :SB-SOURCE-LOCATIONS :SB-TEST :SB-UNICODE
 :SBCL :STACK-ALLOCATABLE-CLOSURES :STACK-ALLOCATABLE-FIXED-OBJECTS
 :STACK-ALLOCATABLE-LISTS :STACK-ALLOCATABLE-VECTORS
 :STACK-GROWS-DOWNWARD-NOT-UPWARD :SYMBOL-INFO-VOPS :UD2-BREAKPOINTS :UNIX
 :UNWIND-TO-FRAME-AND-CALL-VOP :X86-64)
--