bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#16184: 24.3.50; edebug and eval-when-compiler don't work together


From: Anders Lindgren
Subject: bug#16184: 24.3.50; edebug and eval-when-compiler don't work together
Date: Sun, 1 Jan 2017 01:30:44 +0100

Hi Alan!

This time it seems to be working properly with both `eval-when-compile' and `eval-and-compile'!

Happy new year to you too!

    -- Anders

On Sat, Dec 31, 2016 at 5:22 PM, Alan Mackenzie <acm@muc.de> wrote:
Hello again, Anders.

On Fri, Dec 30, 2016 at 09:02:31PM +0100, Anders Lindgren wrote:
> Hi!

> I just got around to test this. Now, `eval-when-comple' seems to be
> working. Unfortunately, `eval-and-comple' is still broken.

> If I do C-u M-C-x eval the following with `debug-on-error' set to t, I get
> the backtrace below:

> (defun test (limit)
>   (eval-and-compile
>     (boundp 'parse-sexp-lookup-properties)))

[ snip backtrace ]

I got a tip from Gemini Lasswell last night.  What is broken is not
edebug.el itself, but the edebug specs applied to various macros.  For
macros like eval-\(when\|and\)-compile, there needs to be an
edebug-enter form compile around the macro.  Most edebug specs don't
compile this - only (I think) def-form and def-body do.  This is not
clearly documented.

Anyhow, I've changed the edebug spec of eval-and-compile to what it
should be (\(cc-\)?eval-when-compile already had it), and I think these
problems are all solved.

Would you please try out the following patch, and let me know sometime
that it's OK, then I can commit it.

Happy New Year again!



diff --git a/lisp/emacs-lisp/byte-run.el b/lisp/emacs-lisp/byte-run.el
index 9d2a048..e680ebb 100644
--- a/lisp/emacs-lisp/byte-run.el
+++ b/lisp/emacs-lisp/byte-run.el
@@ -474,7 +474,7 @@ eval-and-compile
 `progn', except that the value of the _expression_ may be (but is
 not necessarily) computed at load time if eager macro expansion
 is enabled."
-  (declare (debug t) (indent 0))
+  (declare (debug (&rest def-form)) (indent 0))
   ;; When the byte-compiler expands code, this macro is not used, so we're
   ;; either about to run `body' (plain interpretation) or we're doing eager
   ;; macroexpansion.
diff --git a/lisp/emacs-lisp/edebug.el b/lisp/emacs-lisp/edebug.el
index 15b1389..fd3e48d 100644
--- a/lisp/emacs-lisp/edebug.el
+++ b/lisp/emacs-lisp/edebug.el
@@ -2052,15 +2052,10 @@ edebug-stack
 (defvar edebug-stack-depth -1)
 ;; Index of last edebug-stack item.

-(defvar edebug-offset-indices (list 0))
+(defvar edebug-offset-indices nil)
 ;; Stack of offset indices of visited edebug sexps.
 ;; Each function adds one cons.  Top is modified with setcar.
-;; Should be nil at the top level.  No longer!  There are occasions
-;; when this variable is modified by setcar before a cons has been
-;; pushed by `edebug-enter', e.g. when instrumenting
-;; `c-font-lock-declarations' in .../lisp/progmodes/cc-fonts.el.  So
-;; this variable must be initialized to a cons.
-
+;; Should be nil at the top level.
 (defvar edebug-entered nil
   ;; Non-nil if edebug has already been entered at this recursive edit level.
   ;; This should stay nil at the top level.

>     -- Anders

--
Alan Mackenzie (Nuremberg, Germany).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]