Flycheck variable warnings despite flycheck load-path

Question

I'm trying to get Flycheck to load files containing declarations to resolve warnings to free variables etc. But Flycheck is not picking up the (required files. I use (require 'my-dcls) at the top of code files, and (provide 'my-dcls) at the bottom of my declarations file.

I'm running Emacs 24.4 as an app on OSX, and using Flycheck 20160622. I've updated all my packages to the latest available versions using ESC-x list-packages, U.

So far I have learned that:

• Flycheck doesn't use the Emacs load-path, by default policy.

• (setq-default flycheck-emacs-lisp-load-path 'inherit) in the Emacs init file should tell Flycheck to use the Emacs load-path.

• All Flycheck variables are buffer local, so (setq flycheck-emacs-lisp-load-path ..) won't work globally.

• You can (setq-default flycheck-emacs-lisp-load-path (list "dir1" "dir2")) to create a specific load path to your custom files.

So, following all those guidelines,

1. I tried (setq-default flycheck-emacs-lisp-load-path 'inherit) on line 1 of my init file, but without success. I can see the inherit value in every code buffer that I visit when I evaluate flycheck-emacs-lisp-load-path in the minibuffer.

2. I tried (setq-default flycheck-emacs-lisp-load-path (list "dir1" "dir2")) on line 1 of my init file, but without success. I can see the ("dir1" "dir2") value in every code buffer that I visit when I evaluate flycheck-emacs-lisp-load-path in the minibuffer.

3. In both of those cases, (member 'my-dcls features) shows that my declarations file feature has been loaded, which means that Emacs (not necessarily Flycheck) has found and loaded the files successfully (so they do exist).

And still, Flycheck prints out free variable warnings to variables that are defined in my declarations file with (defvar my-variable) statements. If I kill and yank those same defvar statements from the declarations file into the current code buffer, Flycheck stops complaining.

I'm really at a loss to know what to do next. Everything seems in order, but the results say otherwise.

See also this related post here, which is a near duplicate (except that the suggested answers don't work for me on my machine configuration).

Here is my entire .emacs init file, to make sure that nothing else interferes with Flycheck.

(setq-default flycheck-emacs-lisp-load-path
              (list "/Users/me/Dropbox/emacs/"))

(when (>= emacs-major-version 24)
  (require 'package)
  (add-to-list 'package-archives '("melpa" . "http://melpa.org/packages/") t)
  (package-initialize)

  (use-package flycheck
    :ensure t
    :defer t))

(require 'flycheck)

After starting Emacs, I read in a Lisp source file that contains (require 'my-dcls), where my-dcls.el resides in the directory named in the flycheck-emacs-lisp-load-path variable, /Users/me/Dropbox/emacs/.

In the source file buffer, I can eval flycheck-emacs-lisp-load-path, and can see the directory I loaded in there. Any ideas for further debugging to get Flycheck to pick up the load path are welcome.

I had a look at the flycheck source, but it seemed beyond me for effective debugging (not sure I have the skills for that yet). Thanks.

Answer 1

The solution to this issue was not in the flycheck load path. Instead, the variable warnings were showing up because the contents of the (require 'my-dcls) were not providing declarations that the byte-compiler liked.

I thought that the following syntax would work, as was suggested in this earlier thread:

;; a reference declaration, so no value was set
(defvar my-global-var)

But in fact a value had to be declared in the (require 'my-dcls) file to keep flycheck and the byte-compiler syntax checkers happy.

;; flycheck warnings went away when a value was set
(defvar my-global-var nil)

I find this behaviour odd, because the first syntax works fine when it is embedded at the top of the file being checked by Flycheck. But at least I have a somewhat better understanding of what is going on, and will not expect the (require 'my-dcls) method to make the warnings disappear.