Error while checking syntax automatically: (error "Lisp nesting exceeds `max-lisp-eval-depth'")

[colonelpanic8]

I get this error whenever i try to use flycheck-mode

I've tried using a very minimal emacs init file that looks like:

(package-initialize)
(setq server-use-tcp t)
(require 'use-package)
(use-package flycheck
  :ensure t
  :config
  (progn
    (setq flycheck-checkers (delq 'emacs-lisp-checkdoc flycheck-checkers))
    (diminish 'flycheck-mode)
    (global-flycheck-mode)))

and i still get the issue

[swsnr]

Can you produce a backtrace with M-x toggle-debug-on-error please?

[colonelpanic8]

Yep. sorry I shoudl have thought to do that.

Debugger entered--Lisp error: (error "Lisp nesting exceeds `max-lisp-eval-depth'")
  signal(error ("Lisp nesting exceeds `max-lisp-eval-depth'"))
  #[257 "\300 \210\301
@A\"\207" [flycheck-report-failed-syntax-check signal] 4 "\n\n(fn ERR)"]((error "Lisp nesting exceeds `max-lisp-eval-depth'"))
  funcall(#[257 "\300 \210\301
@A\"\207" [flycheck-report-failed-syntax-check signal] 4 "\n\n(fn ERR)"] (error "Lisp nesting exceeds `max-lisp-eval-depth'"))
  flycheck-buffer()
  #[0 "\300 \207" [flycheck-buffer] 1 "\n\n(fn)"]()
  funcall(#[0 "\300 \207" [flycheck-buffer] 1 "\n\n(fn)"])
  flycheck-buffer-automatically()
  flycheck-perform-deferred-syntax-check()

uname -v

Darwin Kernel Version 14.0.0: Fri Sep 19 00:26:44 PDT 2014; root:xnu-2782.1.97~2/RELEASE_X86_64

\emacs --version

GNU Emacs 24.4.1
Copyright (C) 2014 Free Software Foundation, Inc.
GNU Emacs comes with ABSOLUTELY NO WARRANTY.
You may redistribute copies of Emacs
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.

[swsnr]

@IvanMalison Where do these nested calls of flycheck-buffer come from?! flycheck-buffer never calls itself again…

Is that really your entire init file? Do you have any hooks set up for Flycheck?

[colonelpanic8]

i started emacs using the -l flag and an init file with exactly the contents posted in the original post. I take it that this does not happen when you run that init file? I can't imagine what else it would be. Let try symlinking my .emacs.d to the one you have under source control.

[colonelpanic8]

The problem is somewhere in flycheck-may-use-checker. Evaluating:

(flycheck-may-use-checker 'emacs-lisp)

causes the max-lisp-eval-depth error for me.

[colonelpanic8]

It appears that the function generated by (flycheck-checker-predicate checker) is what is causing this. When I call that function outside of flycheck-may-use-checker i get the message

#[0 "ÂÀ!ƒ  ?†    ‡ÃÄÅÆÀ$ˆÇ‡" [emacs-lisp predicate flycheck-valid-checker-p lwarn flycheck :warning "%S is no valid Flycheck syntax checker.
Try to reinstall the package defining this syntax checker." nil] 5 "

This will always cause an error
``` elisp
(mapcar (lambda (checker) (message "%s" checker) (flycheck-may-use-checker checker)) flycheck-checkers)

but the checker that causes it varies depending on the major mode of the buffer. json-jsonlint seems to do it a lot.

[swsnr]

@IvanMalison How did you install Flycheck?

[colonelpanic8]

melpa.

[swsnr]

@IvanMalison Can you try to remove it, and then reinstall it?

[colonelpanic8]

I had already tried that, but I just did it again with no luck.

[jeffkowalski]

I have been experiencing the same issue using stock emacs 24.4 plus bbatsov's prelude kit. Happy to give some logs, but first I simply wanted to confirm the issue exists. On Jan 23, 2015 11:55 AM, "IvanMalison" notifications@github.com wrote:

I had already tried that, but I just did it again with no luck.

— Reply to this email directly or view it on GitHub https://github.com/flycheck/flycheck/issues/574#issuecomment-71254837.

[colonelpanic8]

@jeffkowalski Good to know I'm not the only one.

Can you try running the following elisp in various major modes and reporting the output in this issue? (I assume you have cl-lib

(cl-loop for checker being the elements of flycheck-checkers
         if (condition-case nil
                (flycheck-may-use-checker checker)
              ('error
               (message "checker named '%s' failed" checker)
               checker
               ) nil)
         collect checker)

If the list that this code returns is non empty, you can add something like:

(cl-loop for checker being the elements of flycheck-checkers
         if (condition-case nil
                (flycheck-may-use-checker checker)
              ('error
               (message "checker named '%s' failed" checker)
               (setq flycheck-checkers (delq checker flycheck-checkers))
               checker
               ) nil)
         collect checker)

( you might try replacing (setq flycheck-checkers (delq checker flycheck-checkers)) with (flycheck-disable-checker checker) though I wasn't able to get this to work) Which will temporarily disable those checkers as a temporary solution. As a temporary solution.

[jeffkowalski]

For flycheck-checkers set as (ada-gnat asciidoc c/c++-clang c/c++-gcc c/c++-cppcheck cfengine chef-foodcritic coffee coffee-coffeelint coq css-csslint d-dmd elixir emacs-lisp emacs-lisp-checkdoc erlang eruby-erubis fortran-gfortran go-gofmt go-golint go-vet go-build go-test go-errcheck haml handlebars haskell-ghc haskell-hlint html-tidy javascript-jshint javascript-eslint javascript-gjslint json-jsonlint less lua make perl perl-perlcritic php php-phpmd php-phpcs puppet-parser puppet-lint python-flake8 python-pylint python-pycompile r-lintr racket rpm-rpmlint rst rst-sphinx ruby-rubocop ruby-rubylint ruby ruby-jruby rust sass scala scala-scalastyle scss sh-bash sh-posix-dash sh-posix-bash sh-zsh sh-shellcheck slim tex-chktex tex-lacheck texinfo verilog-verilator xml-xmlstarlet xml-xmllint yaml-jsyaml yaml-ruby)

I get the following: checker named 'emacs-lisp' failed checker named 'json-jsonlint' failed (emacs-lisp json-jsonlint)

On Fri, Jan 23, 2015 at 1:16 PM, IvanMalison notifications@github.com wrote:

@jeffkowalski https://github.com/jeffkowalski Good to know I'm not the only one.

Can you try running the following elisp in various major modes and reporting the output in this issue? (I assume you have cl-lib

(cl-loop for checker being the elements of flycheck-checkers if (condition-case nil (flycheck-may-use-checker checker) ('error (message "checker named '%s' failed" checker) checker ) nil) collect checker)

— Reply to this email directly or view it on GitHub https://github.com/flycheck/flycheck/issues/574#issuecomment-71267420.

[colonelpanic8]

I was able to get rid of this error by changing the name of the predicate variable in flycheck-may-use-checker, but I wonder if this has unintended consequences. flycheck seems to be working for me now though...

(defun flycheck-may-use-checker (checker)
  "Whether a generic CHECKER may be used.

Return non-nil if CHECKER may be used for the current buffer, and
nil otherwise."
  (let ((modes (flycheck-checker-modes checker))
        (the-predicate (flycheck-checker-predicate checker)))
    (and (flycheck-valid-checker-p checker)
         (or (not modes) (memq major-mode modes))
         (funcall the-predicate)
         (not (flycheck-disabled-checker-p checker)))))

@lunaryorn any idea why this is working/whether this is an okay fix? I would hope that nothing in the predicate functions cares about the value of the variable predicate...

[swsnr]

That would only make a difference if the variable was not lexically bound. Can you show me the output of M-: (bound-and-true-p predicate)?

[swsnr]

@IvanMalison By the way, did you install Flycheck manually, with M-x package-install or from the package menu, or did you let use-package install it for you?

[colonelpanic8]

I've tried both methods, but it was originally installed by use-package

[swsnr]

@IvanMalison And the output I asked for?

[colonelpanic8]

@lunaryorn (bound-and-true-p predicate) evaluates to nil, but I'm not sure that is the right predicate to use. signficantly, (bound predicate) evaluates to t AND this is likely to be causing the issue (quoting from the possibly outdated emacs wiki):

http://www.emacswiki.org/emacs/DynamicBindingVsLexicalBinding

As you may have noticed, I have added a new warning to the byte-compiler for defvars of variables that don’t have a prefix. This is in preparation for the introduction of lexical scoping: in order not to have to rewrite all the code, the lexbind branch uses ‘let’ both for dynamically-scoped let-bindings and for lexically-scoped let-bindings; where the distinction is based on whether or not a variable has been defvar’d. This is the same system as used in Common-Lisp and it works well in practice, but it requires a bit of care, because every defvar has a global effect: it declares that this variable will use dynamic-scoping wherever it gets let-bound. So if a file uses ‘len’ as a lexically-scoped variable and another file does a (defvar len), we get a conflict that results in the first file being evaluated with a different semantic than expected by the author.

Why does (flycheck-checker-predicate checker) need to be bound to a variable at all? It isn't used twice in the function or anything like that. My proposed solution chose a more obscure name, but I think getting rid of the binding could be good too.

I checked and predicate was defvared elsewhere, which is, in some sense, the real problem here. That still leaves the issue of why the predicate functions are failing when predicate is bound to a value...

[jeffkowalski]

I found a (defvar predicate nil) in my init that I once added to suppress a warning from an ido function which referenced predicate before it had been defined. So, in my case, (boundp predicate) was true at global scope. Removing that definition clears the problem in flycheck-20150125.601 (from melpa), and flycheck now works as expected. That said, while my problem is solved for now, it's still a puzzle why defining predicate would cause the failure in flycheck. Seems there's some fragility somewhere.

[swsnr]

Flycheck relies on lexical binding for closures in many places. Specifically, predicate is closed over when extending predicates in syntax checker definitions. Defining predicate dynamically breaks the lexical environment of these closures and leads to the endless recursion you observed.

Removing the binding is not the solution. Never defining unprefixed variables is. IOW, it's not a Flycheck issue at all. Closing as invalid.

[catesandrew]

Just ran into this issue. And the fix was to remove the defvar predicate. I'm commenting to add the source incase someone stumbles across this issue https://github.com/DarwinAwardWinner/ido-ubiquitous/issues/68

@lunaryorn btw, love flycheck! great job, has all the features from syntastic i missed from vim and then some, great job!!