GNU bug report logs -
#78898
Make read/readevalloop reentrant
Previous Next
Full log
View this message in rfc822 format
"Lynn Winebarger" <owinebar <at> gmail.com> writes:
> 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.
I think the difference is rather subtle, and it's not clear to me the
old behavior, which edebug relies on, is actually better.
The old readevalloop skips whitespace and comments before calling
Vload_read_function. The new code, AFAIT, only calls
lread_skip_insignificant if use_read0.
The problem is that edebug assumes the point position when its
Vload_read_function is called is actually the beginning of the form; it
then uses
(end-of-defun)
(beginning-of-defun)
to jump to what it thinks is the beginning of the defun. But point was
still in the previous defun (before the separating whitespace), so it's
actually the beginning of the previous defun, so we fail to instrument
the correct defun in edebug-tests-step-into-function.
diff --git a/src/lread.c b/src/lread.c
index 3be2f8bd7d2..b247b6251b5 100644
--- a/src/lread.c
+++ b/src/lread.c
@@ -3796,10 +3796,10 @@ readevalloop (Lisp_Object frameptr)
frame->read_expr = false;
/* Handle the most common case first */
/* not sure why the Vpurify_flag/will_dump_p case is special */
+ lread_skip_insignificant (frame);
if (use_read0)
{
/* avoid condition case */
- lread_skip_insignificant (frame);
if (frame->read_eof)
break;
val = read0 (frame);
appears to fix these test failures.
Pip
This bug report was last modified 12 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.