bug#47168: 28.0.50; Infinite recursion in project-root

bug#47168: 28.0.50; Infinite recursion in project-root

[Juri Linkov]

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)
  ...

bug#47168: 28.0.50; Infinite recursion in project-root

[Dmitry Gutov]

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.

bug#47168: 28.0.50; Infinite recursion in project-root

[Stefan Monnier]

> 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?

Not really, no.  We could refrain from providing a default
implementation, and instead add a method to `cl-no-next-method` or
something like that, but I'm not sure it would make much difference.

> That would allow us to break recursion.

But we could use some dynamically-scoped
`project--within-roots-fallback` variable to break such recursion ;-)


        Stefan

bug#47168: 28.0.50; Infinite recursion in project-root

[Dmitry Gutov]

On 17.03.2021 05:54, Stefan Monnier wrote:
> But we could use some dynamically-scoped
> `project--within-roots-fallback` variable to break such recursion;-)

Good idea, thanks!

Applied and pushed.