GNU bug report logs - #9712
defcustom's initial value expression is not byte-compiled

Previous Next

Full log

View this message in rfc822 format

From: "Drew Adams" <drew.adams <at> oracle.com>
To: <9712 <at> debbugs.gnu.org>
Subject: bug#9712: 24.0.50; doc about byte-compiling `defcustom'
Date: Mon, 10 Oct 2011 06:27:14 -0700

Is this maybe more than a doc bug?  In bytecomp.el there is this:

(defun byte-compile-file-form-custom-declare-variable (form)
  (when (byte-compile-warning-enabled-p 'callargs)
    (byte-compile-nogroup-warn form))
  (push (nth 1 (nth 1 form)) byte-compile-bound-variables)
  ;; Don't compile the expression because it may be displayed to the user.
  ;; (when (eq (car-safe (nth 2 form)) 'quote)
  ;;   ;; (nth 2 form) is meant to evaluate to an expression, so if we have the
  ;;   ;; final value already, we can byte-compile it.
  ;;   (setcar (cdr (nth 2 form))
  ;;           (byte-compile-top-level (cadr (nth 2 form)) nil 'file)))

Seems like this non-evaluation is intended, but sounds like the designer is not
sure that's a good idea (?).  What does "because it may be displayed to the
user" mean?  Is the idea that the user would see the byte-compiled value instead
of the code that evaluates to that value?  If so, why is that bad?

At any rate, there is at least a doc bug.  In particular, someone who wraps the
`defcustom' VALUE in `eval-when-compile' will mistakenly expect the evaluation
result to be placed into the byte code as a constant.  S?he will not expect that
VALUE is not evaluated at byte-compile time, even when inside
`eval-when-compile'.

A consequence of the current behavior is that you really cannot use macro calls
in VALUE, unless you are sure that the macro definition will be available also
at load time (i.e., byte-compilation time is not enough).  I ran into this using
macro `kbd' in VALUE.

Previous Next

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