GNU bug report logs - #78898
Make read/readevalloop reentrant

Previous Next

Full log

View this message in rfc822 format

From: Lynn Winebarger <owinebar <at> gmail.com>
To: 78898 <at> debbugs.gnu.org
Cc: Pip Cet <pipcet <at> protonmail.com>, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: bug#78898: Make read/readevalloop reentrant
Date: Thu, 3 Jul 2025 22:47:38 -0400

[Message part 1 (text/plain, inline)]

The attached patch (in addition to the preceding 2) eliminates most of
the errors from "make check".  I've attached the ones from edebug.  I
see "edebug-tests-break-in-lambda-out-of-defining-context" fail in my
build of the master checkout, so that leaves two unexplained failures,
edebug-tests-step-into-function and
edebug-tests-trace-function-call-and-return.  I currently have no idea
what is going on.  The other 67 (or thereabouts) errors were fixed by
1. making the control flow more faithful to the original for
eval-region [ about 35 tests].  I split LREAD_FRAME_MULTIPLE into
LREAD_FRAME_INTEGRAL (where all lisp state changes are integrated) and
LREAD_FRAME_DYNAMIC_WIND (where eval-region provides some protection
of the current buffer state).  The previous version of the code relied
on !NILP(start) to prompt this protective wind-down/wind-up behavior
between read and eval.
2. Ensure that if readfun is called and generates an eof due to the
point moving to the end of the region, any expression returned gets
evaluated before the eof is honored in readevalloop.
3. ensuring that calling "load-read-function" uses the buffer as a
stream argument if that is the input for the frame.  Edebug relies on
this undocumented behavior in advising load-read-function to
instrument code being debugged [20+ tests].
4. Getting rid of the new signal handlers used to bypass frames - may
have been responsible for one or two test failures.  They were mainly
an experiment to understand how the dynamic stack works and if a more
explicit dynamic-wind type behavior would work if code rand while
processing a maybe_quit.  I'm not sure if this changes an observed
test results, but it doesn't really do anything useful beyond testing
how the idea might actually work.  So, calls to read are still
susceptible to eof signals generated but not handled by elisp code run
while reading the stream.

I can't perceive any difference in startup time with the debug build
compiled without support for native compilation.

Overall results of 'make check'
SUMMARY OF TEST RESULTS
-----------------------
Files examined: 533
Ran 8119 tests, 7959 results as expected, 27 unexpected, 133 skipped
4 files contained unexpected results:
  lisp/vc/vc-tests/vc-tests.log
  lisp/progmodes/python-tests.log
  lisp/progmodes/c-ts-mode-tests.log
  lisp/emacs-lisp/edebug-tests.log

For the non-edebug tests, I get the same failures for my reference
checkout on my test system.
I'd be happy to take any hints on those two remaining edebug
regressions.  I have no idea what the difference of interest is
between those two and all the other similar looking tests is, in terms
of reliance on the behavior of
eval-region/eval-buffer/load-read-function.

[0003-Reverted-over-regularization-of-control-flow.patch (text/x-patch, attachment)]

[ert-failures-0003.el (text/x-emacs-lisp, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.