[COMMIT] Keep around gensym correspondence information through entire bytecomp files

[Aidan Kehoe]

 Ar an dara lá de mí na Nollaig, scríobh Stephen J. Turnbull: 

 >  > 	* bytecomp.el (byte-compile-output-file-form):
 >  > 	Bind print-gensym to a cons, to tell the Lisp printer not to clear
 >  > 	print-gensym-alist on exit from #'print. This is appropriate
 >  > 	because #'byte-compile-output-file-form may be called multiple
 >  > 	times for a given output file, and re-using the
 >  > 	#1=#:... placeholders in that context is inappropriate. 
 > 
 > do you mean "reusing placeholders is APPROPRIATE" here?  I think you
 > should be a little more explict if not.  Do you mean something like
 > "continuing to increment the placeholders is appropriate" rather than
 > "reusing the placeholders is inappropriate"?

This ChangeLog was unclear and muddled because I was trusting the
implementation of the (eq t print-gensym) behaviour to not be buggy--I
thought the problem was in the byte compiler. That wasn’t it, though; the
behaviour of the Lisp printer when you revert this change and recompile
mule/*.elc is what’s broken. The non-boilerplate code of greek.elc if you do
that looks like this:

(byte-code "[byte codes omitted]" [#1=#:G79030 #2=#:G79075 #3=#:G79053 #4=#:G79031 #5=#:G79029 [lots and lots of constants omitted] #1=#:G79032 upper lower greek latin-1 case-table syntax-table case-fold-search] 12)

This means that somewhere in the guts of the printing of those [lots and
lots of constants], one of the print functions reset print-gensym-alist
where it shouldn’t have. A bit of browsing doesn’t tell me which, but it
should be possible to set a watchpoint on it and work it out. The Cygwin GDB
isn’t being co-operative with me in this right now, though. 

We (and GNU) normally don’t see this problem because for defvars, defuns,
defmacros, defconst and autoloads, print-gensym was always bound to a cons,
so the print-gensym-as-t behaviour wasn’t thoroughly tested.

This is actually, slightly to my surprise, independent of the emacs-w3m
problem. The issue with the latter is that readevalloop resets Vread_objects
with each new top level form--see lread.c:1490--so it is impossible to
re-use an uninterned symbol from one call to (byte-code ...) to the next. 
One #'custom-declare-variable call using one uninterned symbol followed by
another re-using the same symbol will always break.

 > A comment at the point of change would be appropriate, here.
 > 
 > Does this change the behavior of byte-compiled libraries?

-- 
¿Dónde estará ahora mi sobrino Yoghurtu Nghé, que tuvo que huir
precipitadamente de la aldea por culpa de la escasez de rinocerontes?