GNU bug report logs -
#13605
24.3.50; Eager macro-expansion failure: (void-variable ruby-syntax-methods-before-regexp) when ruby-mode is not compiled
Previous Next
Reported by: Dmitry Gutov <dgutov <at> yandex.ru>
Date: Fri, 1 Feb 2013 21:37:02 UTC
Severity: normal
Found in version 24.3.50
Done: Stefan Monnier <monnier <at> iro.umontreal.ca>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your message dated Fri, 08 Feb 2013 11:18:42 -0500
with message-id <jwvhalm93v6.fsf-monnier+bug#13605 <at> gnu.org>
and subject line Re: bug#13605: 24.3.50; Eager macro-expansion failure: (void-variable ruby-syntax-methods-before-regexp) when ruby-mode is not compiled
has caused the debbugs.gnu.org bug report #13605,
regarding 24.3.50; Eager macro-expansion failure: (void-variable ruby-syntax-methods-before-regexp) when ruby-mode is not compiled
to be marked as done.
(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)
--
13605: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13605
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
This applies both to trunk and emacs-24.
ruby-mode compiles without warnings, and ruby-syntax-propertize-function
works fine either way, but when ruby-mode is not compiled, it shows the
subject warning upon loading, and ruby-syntax-propertize-function is an
order of magnitude slower (not very noticeable in the simple cased, though),
due to syntax-propertize-rules not being expanded.
The constant in question is defined in an `eval-and-compile' block, I
can't see what else could the interpreter need. Help?
In GNU Emacs 24.3.50.2 (x86_64-unknown-linux-gnu, GTK+ Version 3.6.0)
of 2013-01-27 on vbx
Bzr revision: 111609 michael.albinus <at> gmx.de-20130127104333-93qmx98ovt4m0y5q
Windowing system distributor `The X.Org Foundation', version 11.0.11300000
System Description: Ubuntu 12.10
[Message part 3 (message/rfc822, inline)]
>>> Maybe the better way to fix it (for trunk) is to change eval-and-compile
>>> (and probably eval-when-compile) so that it evaluates its argument during
>>> macro-expansion.
I've installed the patch below which fixes this problem and hopefully
won't introduce others.
Stefan
=== modified file 'lisp/emacs-lisp/byte-run.el'
--- lisp/emacs-lisp/byte-run.el 2013-01-03 02:37:57 +0000
+++ lisp/emacs-lisp/byte-run.el 2013-02-08 16:13:13 +0000
@@ -392,15 +392,15 @@
Thus, the result of the body appears to the compiler as a quoted constant.
In interpreted code, this is entirely equivalent to `progn'."
(declare (debug t) (indent 0))
- ;; Not necessary because we have it in b-c-initial-macro-environment
- ;; (list 'quote (eval (cons 'progn body)))
- (cons 'progn body))
+ (list 'quote (eval (cons 'progn body) lexical-binding)))
(defmacro eval-and-compile (&rest body)
"Like `progn', but evaluates the body at compile time and at load time."
(declare (debug t) (indent 0))
- ;; Remember, it's magic.
- (cons 'progn body))
+ ;; 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.
+ (list 'quote (eval (cons 'progn body) lexical-binding)))
(put 'with-no-warnings 'lisp-indent-function 0)
(defun with-no-warnings (&rest body)
This bug report was last modified 12 years and 108 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.