Re: Towards a cleaner build: calc.el

[Stefan Monnier <monnier@iro.umontreal.ca>]

> ;;; Faster in-line version zerop, normalized values only.
> (defsubst Math-zerop (a)		; [P N]
>   (if (consp a)
>       (and (not (memq (car a) '(bigpos bigneg)))
> 	   (if (eq (car a) 'float)
> 	       (eq (nth 1 a) 0)
> 	     (math-zerop a)))
>     (eq a 0)))

There's indeed an ordering issue with defsubst:
when compiling a call to a defsubst such as Math-zerop, if Math-zerop is
already compiled, then we inline its bytecode (this is done at the level
of the "lapcode"), whereas if it's not compiled yet, then we inline the
source code directly.

Of course, to make things more interesting, this is only half-true: if
the lexical-binding of the two files is different, then even if the
function is not yet compiled, we don't inline its source code, instead
we first compile it and then inline its bytecode (to avoid having to
compile code that's a mix of lexical-binding and dynamic-binding).

Arguably, we should drop support for inlining the source code and just
always byte-compile the function before inlining it to avoid those
side-effects.
See byte-compile-inline-expand if you're interested in this.


        Stefan