semantics of `defvar' and `defconst' change when byte-compiling

[Matt Swift]

DEFVAR

>From the documentation of `defvar':

    defvar is a special form.
    (defvar SYMBOL &optional INITVALUE DOCSTRING)
    [...]
    If INITVALUE is missing, SYMBOL's value is not set.

Indeed the C code implementing `defvar' ("eval.c") does nothing when
there is no INITVALUE.

But the semantics are different to the byte-compiler
(`byte-compile-file-form-defvar' in "bytecomp.el"), which does not
distinguish declarations with no INITVALUE and therefore silences
byte-compiler warning by adding SYMBOL to
`byte-compile-bound-variables'.

Actually that is true only for "file-level" `defvar' and `defconst'
with doc strings.  The rest are handled by `byte-compile-defvar' (also
"bytecomp.el"), which does distinguish this case and I think does the
right thing.

The idiom in the short test file below seems to be a very common way
to suppress byte-compilation warnings, so I do not think the semantics
of the byte-compiler should change.  And I would guess it would also
be very bad to change the semantics of the normal `defvar', e.g.,
binding SYMBOL to nil when there is no INITVALUE.  So I think
documenting this behavior is the best way to address it.

;; (makunbound 'x)

;; omit and you get a byte-compilation warning
(eval-when-compile (defvar x))

(defun falconidae ()
  (eq x 0))


DEFCONST

The situation is worse for `defconst'.  The C function requires two
arguments, but the byte-compiler does not, so loading the
following file as source raises an error, but it compiles without a
warning and loads without a warning, leaving 'y unbound.

(defconst y)

Probably the byte-compiler should barf instead, because it seems to
make less sense to change the C to permit `defconst' to lack an
INITVALUE like `defvar'.