bug#3892: corrupting load-in-progress value with "let"

[Ken Raeburn]

With these source files:

==> test.el <==
(message "test:  load-in-progress %S" load-in-progress)
(let ((load-path (cons "." load-path)))
  (load "test2"))
(message "test:  load-in-progress %S" load-in-progress)

==> test2.el <==
(message "test2: load-in-progress %S" load-in-progress)
(load "test3")
(message "test2: load-in-progress %S" load-in-progress)

==> test3.el <==
(message "test3: load-in-progress %S" load-in-progress)

and test.el and test2.el byte-compiled but test3.el only present in  
source form, the resulting output shows that load-in-progress is  
inconsistent:

% ./b/Inst/bin/emacs --batch -l test.elc
test:  load-in-progress t
Loading test2...
test2: load-in-progress t
Loading /tmp/emacs-23.0.96/test3.el (source)...
test3: load-in-progress t
test2: load-in-progress t
test:  load-in-progress nil
%

I'm working with the CVS sources and 23.0.96 prerelease code, but can  
reproduce the behavior in 22.1 as shipped with Mac OS X.

The variable load-in-progress is defined in the C code with  
DEFVAR_BOOL applied to an int variable.  Since file loading can be  
invoked recursively, the int value is incremented and decremented when  
loading begins and ends, and should in theory be zero only when no  
file is being loaded.

However, if we're loading a .el file from source, the C code in  
lread.c:Fload calls out to the load-source-file-function, which winds  
up calling code in mule.el, which uses "let" on load-in-progress.  The  
let/unwind support doesn't save and restore the integer value for a  
Lisp_Misc_Boolfwd variable, just the boolean state.  So after loading  
of test3.el finishes above, load-in-progress is restored from its old  
*boolean* value, and gets the value 1 instead of 2 as it should have.   
When test2.elc is done loading, it drops to zero and it looks like  
we're not currently loading any files, even though we're in the middle  
of loading test.elc still.

There is code (in C mode, among others) which checks whether a file is  
being loaded, so this can have a behavioral impact under certain  
conditions.  I haven't actually triggered the problem in my normal  
usage patterns though.

On the assumption that DEFVAR_BOOL variables really ought to just be  
used as booleans (I haven't checked other boolean variables though),  
and we don't want to change the Lisp-visible binding to an integer (or  
"if load-in-progress" would stop working right), I'm working on a  
patch to make load-in-progress an actual boolean, and put the file- 
loading depth counter elsewhere, inaccessible to Lisp (since it's  
inaccessible now).

Ken