GNU bug report logs - #47168
28.0.50; Infinite recursion in project-root

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Juri Linkov <juri <at> linkov.net>, 47168 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Subject: bug#47168: 28.0.50; Infinite recursion in project-root
Date: Wed, 17 Mar 2021 04:47:15 +0200

Hi Juri,

On 15.03.2021 19:04, Juri Linkov wrote:
> When for some reason the argument of 'project-root' becomes nil,
> for example, when the current buffer is not under version control,
> then
> 
>    (project-root (project-current))
> 
> goes into infinite recursion:
> 
> Debugger entered--Lisp error: (error "Lisp nesting exceeds ‘max-lisp-eval-depth’")
>    project-root(nil)
>    project-roots(nil)
>    ...
>    project-root(nil)
>    project-roots(nil)
>    ...

Note that the right way to write this code is either

  (project-root (project-current t))

or

  (when-let ((project (project-current)))
    (project-root project))

so we only see this when the programmer failed to account for the 
absence of current project.

Still, it would be nice to never show a backtrace like this, even in 
those cases.

The idea here was to keep compatibility with backends which implement 
project-roots and not project-root (perhaps the built-in vc backend in 
Emacs 27), as well as let the clients call either project-root or 
project-roots, also for backward compatibility purposes. Worst case, we 
can give up on that and require all 3rd party code standardize on 
project-root and have all users install the latest project.el from ELPA.

But perhaps we still can have it both ways?

Stefan, any chance there's a relatively non-dirty way we can check 
whether there is a non-default implementation for the generic function 
with given args, before calling it? That would allow us to break recursion.

Previous Next

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