Yes, finally: a function that tells you the name of the file where
the code is located. Finding this name is non-trivial in practice,
as evidenced by the "4 shift/reduce conflicts" warning when compiling
CEDET's python.el, because its `wisent-source` got it wrong in that
case, thinking the grammar came from `python.el` instead of
`python-wy.el`.
While at it, also made `macroexp-compiling-p` public, since it's
useful at various places.
(macroexp-compiling-p): Rename from `macroexp--compiling-p`.
* lisp/emacs-lisp/bytecomp.el (byte-compile-close-variables):
Bind `load-file-name` to nil so we can distinguish a load that calls
the byte compiler from a byte compilation which causes a load.
* lisp/cedet/semantic/wisent/python.el (wisent-python--expected-conflicts):
Remove; it was just a workaround.
* lisp/subr.el (do-after-load-evaluation): Avoid `byte-compile--` vars.
* lisp/cedet/semantic/fw.el (semantic-alias-obsolete):
Use `macroexp-compiling-p` and `macroexp-file-name`.
* lisp/cedet/semantic/wisent/comp.el (wisent-source): Use `macroexp-file-name`
(wisent-total-conflicts): Tighten regexp.
* lisp/emacs-lisp/cl-lib.el (cl--compiling-file): Delete function
and variable. Use `macroexp-compiling-p` instead.
* lisp/progmodes/flymake.el (flymake-log):
* lisp/emacs-lisp/package.el (package-get-version):
* lisp/emacs-lisp/ert-x.el (ert-resource-directory):
Use `macroexp-file-name`.
* lisp/emacs-lisp/bytecomp.el (byte-compile-make-closure):
Use the supplied doc string if it's a literal; fall back to the old
slow way of building a closure otherwise.
Simplify closure creation by calling a single function at run time
instead of putting it together from small pieces. This is faster
(by about a factor 2), takes less space on disk and in memory, and
makes internal functions somewhat readable in disassembly listings again.
This is done by creating a prototype function at compile-time whose
closure variables are placeholder values V0, V1... which can be seen
in the disassembly. The prototype is then cloned at run time using
the new make-closure function that replaces the placeholders with
the actual closure variables.
* lisp/emacs-lisp/bytecomp.el (byte-compile-make-closure):
Generate call to make-closure from a prototype function.
* src/alloc.c (Fmake_closure): New function.
(syms_of_alloc): Defsubr it.
* src/data.c (syms_of_data): Defsym byte-code-function-p.
* doc/lispref/commands.texi (Using Interactive): Document the
extended `interactive' form.
* doc/lispref/loading.texi (Autoload): Document list-of-modes
form.
* lisp/emacs-lisp/autoload.el (make-autoload): Pick the list of
modes from `interactive' out of the functions.
* lisp/emacs-lisp/bytecomp.el (byte-compile-lambda): Allow for the
extended `interactive' form.
* src/callint.c (Finteractive): Document the extended form.
* src/data.c (Finteractive_form): Return the interactive form in
the old format (even when there's an extended `interactive') to
avoid having other parts of Emacs be aware of this.
(Fcommand_modes): New defun.
* src/emacs-module.c (GCALIGNED_STRUCT): Allow for modules to
return command modes.
* src/lisp.h: New function module_function_command_modes.
The recent change in macroexp triggered a cyclic dependency error
during eager macroexpansion when neither `bytecomp` nor `byte-opt` had
been byte-compiled yet. This fixes it by moving the offending
function to macroexp.el.
* lisp/emacs-lisp/macroexp.el (macroexp--unfold-lambda): Move from
byte-opt.el and rename.
(macroexp--expand-all): Use it.
* lisp/emacs-lisp/byte-opt.el (byte-compile-unfold-lambda): Move to
macroexp.el.
(byte-compile-inline-expand, byte-optimize-form-code-walker):
* lisp/emacs-lisp/bytecomp.el (byte-compile-form):
Use `macroexp--unfold-lambda` instead.
* lisp/emacs-lisp/eieio-core.el (eieio-defclass-autoload): Try to make
the wording of the warning about the obsoleted variable less confusing.
* lisp/emacs-lisp/bytecomp.el (byte-compile-check-variable): Don't
warn for lexical variables (Bug#39169). Fix spurious `or'.
* test/lisp/emacs-lisp/bytecomp-tests.el
(bytecomp/warn-obsolete-variable-bound\.el): New test.
* test/lisp/emacs-lisp/bytecomp-resources/warn-obsolete-variable-bound.el:
New file.
* lisp/emacs-lisp/bytecomp.el (byte-compile-file): Don’t fail if
target filename doesn’t contain a directory name.
* test/lisp/emacs-lisp/bytecomp-tests.el
(bytecomp-tests--target-file-no-directory): New unit test.
See Bug#44631. While testing for a readonly output directory has
slightly different semantics, in practice they should cover cases
where Emacs is sandboxed and can only write to the destination file,
not its directory.
* lisp/emacs-lisp/bytecomp.el (byte-compile-file): Handle the case
where the output directory is not writable.
* test/lisp/emacs-lisp/bytecomp-tests.el
(bytecomp-tests--not-writable-directory)
(bytecomp-tests--dest-mountpoint): New unit tests.
(byte-compile--default-dest-file): New function, extracted from
byte-compile-dest-file.
(byte-compile-dest-file): Use it.
(byte-compile-dest-file-function): Give it a non-nil default value.
(byte-recompile-file, byte-compile-file): Handle a nil return value
from `byte-compile-dest-file`.
* lisp/progmodes/elisp-mode.el (elisp-flymake--batch-compile-for-flymake):
Tell the compiler not to write the result, instead of writing it to
a dummy temp file.
* lisp/emacs-lisp/bytecomp.el (byte-compile-warning-types)
(byte-compile-warnings, byte-compile-cl-file-p)
(byte-compile-eval, byte-compile-eval-before-compile)
(byte-compile-arglist-warn, byte-compile-find-cl-functions)
(byte-compile-cl-warn, displaying-byte-compile-warnings)
(byte-compile-file-form-require, byte-compile-form): Remove all
specific cl.el warnings, as that library is now obsolete. The
regular obsoletion warnings are sufficiently discouraging.
* lisp/emacs-lisp/advice.el (ad-compile-function): Don't try to
silence the now removed warning.
* doc/lispref/tips.texi (Coding Conventions):
* doc/misc/cl.texi (Organization): Make recommendation to not use
cl.el and cl-compat.el stronger.
* lisp/obsolete/cl.el: Make alias help say that they are obsolete.
* lisp/obsolete/cl-compat.el (build-klist, safe-idiv)
(pair-with-newsyms): Silence byte-compiler.
* lisp/emacs-lisp/bytecomp.el (byte-native-qualities): Define
variable.
(byte-compile-from-buffer): Spill compilation qualities.
* lisp/emacs-lisp/comp.el (comp-speed, comp-debug): Make
them file local variables.
(comp-ctxt): Add `speed' and `debug' slots.
(comp-spill-speed, comp-spill-lap-function): Make use of these.
(comp-spill-lap-function): Spill qualities from
`byte-native-qualities'.
(comp-limplify-top-level): Do not use `comp-speed' but ctxt value
unstead.
(comp-final): Do not propagate qualities as they are already
in the `comp-ctxt'.
(comp--native-compile): Close on `byte-native-qualities'.
* src/comp.c (comp_t): Add 'speed' and 'debug' fields.
(emit_comment, emit_mvar_rval, emit_static_object)
(emit_ctxt_code, Fcomp__init_ctxt): Use these instead of the
global variables.
(Fcomp__compile_ctxt_to_file): Set comp.speed and comp.debug and
use them.
* lisp/emacs-lisp/bytecomp.el (byte-compile-file): Bind
`byte-compiler-error-flag' instead of setting it (bug#41065).
This fixes a problem of "leaking" the flag when compiling
something that then compiles something that errors out (i.e., an
"inner" compile).
* lisp/progmodes/dcl-mode.el (dcl-mode):
* lisp/progmodes/idlw-complete-structtag.el: Recommend
with-eval-after-load instead of load-hooks.
* lisp/calc/calc-ext.el (calc-ext-load-hook):
* lisp/emacs-lisp/bytecomp.el (bytecomp-load-hook):
* lisp/emacs-lisp/cl-extra.el (cl-extra-load-hook):
* lisp/emacs-lisp/cl-macs.el (cl-macs-load-hook):
* lisp/emacs-lisp/cl-seq.el (cl-seq-load-hook):
* lisp/gnus/message.el (message-load-hook):
* lisp/gnus/nnheader.el (nnheader-load-hook):
* lisp/gnus/nnmail.el (nnmail-load-hook):
* lisp/progmodes/dcl-mode.el (dcl-mode-load-hook):
* lisp/textmodes/tex-mode.el (tex-mode-load-hook):
* lisp/whitespace.el (whitespace-load-hook): Obsolete for
with-eval-after-load. Note that these variables are never declared,
but the byte-compiler will still warn about them if used.
Find lexical use of variables that are dynamically declared in other
files by recording 'defvar' declarations in files that can be read
in by the compiler in a second compilation. This is particularly
useful when converting code to use lexical-binding.
The facility is controlled by setting environment variables:
EMACS_GENERATE_DYNVARS -- set to non-empty to generate a .dynvars file
corresponding to each .elc.
EMACS_DYNVARS_FILE -- set to the name of a .dynvars file to use
as defvar information during compilation,
enabling the new warnings.
* lisp/emacs-lisp/bytecomp.el (byte-compile--known-dynamic-vars)
(byte-compile--seen-defvars): New variables.
(byte-compile-warning-types): Add lexical-dynamic warning.
(byte-compile--load-dynvars, byte-compile--warn-lexical-dynamic):
New functions.
* lisp/emacs-lisp/bytecomp.el (byte-compile-file, byte-compile--declare-var)
(byte-compile-lambda, byte-compile-bind): Add dynamic variable loads,
dumps and checks.
* doc/lispref/variables.texi (Converting to Lexical Binding): Document.
* lisp/emacs-lisp/autoload.el (update-directory-autoloads):
.eln files have been moved so remove the '.eln' match.
* lisp/emacs-lisp/bytecomp.el (byte-compile-refresh-preloaded):
Likewise.
* lisp/emacs-lisp/find-func.el (find-library-suffixes): Clean-up
as '.eln' is no more in `load-suffixes'.
* lisp/help-fns.el (find-lisp-object-file-name): Clean-up as
`symbol-file' will return the '.elc' file.
* src/lread.c (Fget_load_suffixes): Remove logic as '.eln' is not
anymore in load-suffixes.
(openp): Two spaces.
This bug affected compilation of
(cond ((member '(some list) variable) ...) ...)
While equal is symmetric, member is not; in the latter case the
arguments must be a variable and a constant list, in that order.
Reported by Ikumi Keita.
* lisp/emacs-lisp/bytecomp.el (byte-compile--cond-switch-prefix):
Don't treat equality and member predicates in the same way; only
the former are symmetric in their arguments.
* test/lisp/emacs-lisp/bytecomp-tests.el
(byte-opt-testsuite-arith-data): Add test cases.
* lisp/emacs-lisp/bytecomp.el (byte-compile-file): Do not crash if
native compiling we have no permission to create the .elc
file. We are not creating it.
