GNU bug report logs - #56292
29.0.50; Problem with define-obsolete-function-alias in loaddefs.el

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 56292 in the body.
You can then email your comments to 56292 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; Compilation failure since recent loaddefs speed up
Date: Tue, 28 Jun 2022 22:20:14 -0700

Hello,

When I try to byte compile bongo.el[1] with recent master I get this
strange error:

    ~/tmp/bongo.el:5341:35: Error: Wrong type argument: sequencep, 0

Line 5341 is this:

        (defun bongo-player-update-elapsed-time (player elapsed-time)
      "Set PLAYER's `elapsed-time' property to ELAPSED-TIME,
    unless PLAYER's last seek happened less than N seconds ago, where N
    is the value of PLAYER's `time-update-delay-after-seek' property."
      (let ((delay (bongo-player-get player 'time-update-delay-after-seek)))
        (when (or (null delay) (zerop delay)
                  (let ((time (bongo-player-get player 'last-seek-time)))
                    (or (null time)
                        (time-less-p (seconds-to-time delay)
  >>>> this one >>>>                 (subtract-time (current-time) time)))))
          (bongo-player-put player 'elapsed-time elapsed-time))))

which doesn't look suspicious.

Git bisection says 1d4e903417 is the first bad commit.  I did a
bootstrap build for each step of the bisection, with this script:

    git clean -xdff
    make -j4 || exit 125
    src/emacs --batch -f batch-byte-compile ~/tmp/bongo.el || exit 1

Presumably the error is coming from a type error somewhere in the
bytecompilation machinery, rather than this line in bongo.el?

[1]  https://github.com/dbrock/bongo/blob/master/bongo.el

-- 
Sean Whitton

Message #8 received at 56292 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 56292 <at> debbugs.gnu.org
Subject: Re: bug#56292: 29.0.50; Compilation failure since recent loaddefs
 speed up
Date: Wed, 29 Jun 2022 12:23:02 +0200

Sean Whitton <spwhitton <at> spwhitton.name> writes:

> When I try to byte compile bongo.el[1] with recent master I get this
> strange error:
>
>     ~/tmp/bongo.el:5341:35: Error: Wrong type argument: sequencep, 0

Do you have a backtrace for this error?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #13 received at 56292 <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 56292 <at> debbugs.gnu.org
Subject: Re: bug#56292: 29.0.50; Compilation failure since recent loaddefs
 speed up
Date: Wed, 29 Jun 2022 08:43:57 -0700

Hello,

On Wed 29 Jun 2022 at 12:23pm +02, Lars Ingebrigtsen wrote:

> Sean Whitton <spwhitton <at> spwhitton.name> writes:
>
>> When I try to byte compile bongo.el[1] with recent master I get this
>> strange error:
>>
>>     ~/tmp/bongo.el:5341:35: Error: Wrong type argument: sequencep, 0
>
> Do you have a backtrace for this error?

No, as it doesn't happen interactively.  What's the easiest way to get
one out of --batch?

-- 
Sean Whitton

Message #16 received at 56292 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 56292 <at> debbugs.gnu.org
Subject: Re: bug#56292: 29.0.50; Compilation failure since recent loaddefs
 speed up
Date: Thu, 30 Jun 2022 11:15:35 +0200

Sean Whitton <spwhitton <at> spwhitton.name> writes:

>>>     ~/tmp/bongo.el:5341:35: Error: Wrong type argument: sequencep, 0
>>
>> Do you have a backtrace for this error?
>
> No, as it doesn't happen interactively.  What's the easiest way to get
> one out of --batch?

Normal errors should give you a backtrace by default in --batch, but I
guess whatever is generating the message here is catching the error.
Try perhaps (setq debug-on-signal t) and see whether that gives a
backtrace?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #19 received at 56292 <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: control <at> debbugs.gnu.org, 56292 <at> debbugs.gnu.org
Subject: Re: bug#56292: 29.0.50; Compilation failure since recent loaddefs
 speed up
Date: Thu, 30 Jun 2022 11:16:32 -0700

retitle 56292 29.0.50; Problem with define-obsolete-function-alias in loaddefs.el
thanks

On Thu 30 Jun 2022 at 11:15am +02, Lars Ingebrigtsen wrote:

> Normal errors should give you a backtrace by default in --batch, but I
> guess whatever is generating the message here is catching the error.
> Try perhaps (setq debug-on-signal t) and see whether that gives a
> backtrace?

Thanks, I eventually managed to get some useful output.

After 1d4e903417, before time-date is loaded, (get 'subtract-time
'byte-obsolete-info) yields (time-subtract nil 0).  Previously, whether
or not time-date was loaded, it yielded (time-substract nil "26.1").
The wrong-type-argument is when macroexp--obsolete-warning tries to pass
0 as an argument to concat.

If you replace

    (define-obsolete-function-alias 'subtract-time 'time-subtract "\
26.1")

with

    (define-obsolete-function-alias 'subtract-time 'time-subtract "26.1")

in loaddefs.el then the problem goes away.  I hacked loadup.el and
determined that when loadup.el is loading loaddefs.el,

    (macroexpand-1
     '(define-obsolete-function-alias 'subtract-time 'time-subtract "\
26.1"))

yields

(progn (defalias 'subtract-time 'time-subtract nil)
       (make-obsolete 'subtract-time 'time-subtract 0))

which is not the correct expansion according to the definition of
define-obsolete-function-alias ..

-- 
Sean Whitton

Message #24 received at 56292 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: control <at> debbugs.gnu.org, 56292 <at> debbugs.gnu.org
Subject: Re: bug#56292: 29.0.50; Compilation failure since recent loaddefs
 speed up
Date: Thu, 30 Jun 2022 20:21:40 +0200

Sean Whitton <spwhitton <at> spwhitton.name> writes:

> If you replace
>
>     (define-obsolete-function-alias 'subtract-time 'time-subtract "\
> 26.1")
>
> with
>
>     (define-obsolete-function-alias 'subtract-time 'time-subtract "26.1")
>
> in loaddefs.el then the problem goes away.

Hm.  Yes, I'll change it to format the string without the \ (because
only doc strings should be formatted that way), but this is pretty bizarre.

> I hacked loadup.el and
> determined that when loadup.el is loading loaddefs.el,
>
>     (macroexpand-1
>      '(define-obsolete-function-alias 'subtract-time 'time-subtract "\
> 26.1"))
>
> yields
>
> (progn (defalias 'subtract-time 'time-subtract nil)
>        (make-obsolete 'subtract-time 'time-subtract 0))
>
> which is not the correct expansion according to the definition of
> define-obsolete-function-alias ..

"\
26.1"

and

"26.1"

should yield an identical string after it's been read by the lisp
reader, so I don't understand how it could be making a difference here.  

Unless makedoc is involved somehow...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #27 received at 56292 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: control <at> debbugs.gnu.org, 56292 <at> debbugs.gnu.org
Subject: Re: bug#56292: 29.0.50; Problem with define-obsolete-function-alias
 in loaddefs.el
Date: Tue, 02 Aug 2022 13:08:53 +0200

Sean Whitton <spwhitton <at> spwhitton.name> writes:

> The wrong-type-argument is when macroexp--obsolete-warning tries to pass
> 0 as an argument to concat.
>
> If you replace
>
>     (define-obsolete-function-alias 'subtract-time 'time-subtract "\
> 26.1")
>
> with
>
>     (define-obsolete-function-alias 'subtract-time 'time-subtract "26.1")
>
> in loaddefs.el then the problem goes away.

Aha!  This is due to this code:

  /* If purifying, and string starts with \ newline,
     return zero instead.  This is for doc strings
     that we are really going to find in etc/DOC.nn.nn.  */
  if (!NILP (Vpurify_flag) && NILP (Vdoc_file_name) && cancel)
    {
      unbind_to (count, Qnil);
      return make_fixnum (0);
    }

Which will be removed after bug#53024 is done.

But the fixes I did to loaddefs-gen in this bug report fixed this bug
report, so I'm closing it.

Previous Next

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