Given the following setup, how is this package adding extra value?

1. llvm/clang installed
2. irony-mode
3. flycheck and irony-flycheck.

I can already see programming errors on the fly, so I am not sure how is the clang-analyzer any different?

I see this being reported in the minibuffer when opening a C file:

Suspicious state from syntax checker clang-analyzer: Flycheck checker clang-analyzer returned non-zero exit code 1, but its output contained no errors: In file included from /home/user/testinit.c:327:

Parsing the compile options does not work when -fcolor-diagnostics is present in the compilation databases.

This code try to fix this:

  :command ("clang"
	    "-fno-color-diagnostics" ; don't include color in output
	    "-fno-caret-diagnostics" ; don't indicate location in output
	    "-fno-diagnostics-show-option" ; don't show warning group
	    "--analyze"
	    (eval (flycheck-clang-analyzer--get-compile-options))
            source-inplace)

However, this code adds the -fno-color-diagnostics option BEFORE the compilation database options,
it should add it AFTER so that the compilation database is overriden.

Does this plugin support Ccls?It is a fork of cquery.

Hi Alex,
I started noticing flycheck files in the source and header directories. For c files they have the extension .plist and for the headers .gch:
flycheck_source.plist
flycheck_header.gch

I noticed them because they show up before I make commits and I have to go delete them manually before pushing my changes to the main repo.

I also noticed that these files are generated only when flycheck-clang-analyzer is enabled. Is there a way to disable generating these files?

Hello,

Everything works as expected in a minimal example of

#include <stdio.h>
#include <limits>
#include <stdlib.h>


int main() {
  void *p = malloc(1000);
  return 0;
}

But when I try it on an actual project, it is not working. I am using irony and rtags on the same codebase and a .clang_completion and a compile_commands.json file is at the root of the source tree.

If I navigate to a .cxx of this project and run flycheck-compile with clang-analyzer I merely get "Cannot use syntax checker clang-analyzer in this buffer" in the message-buffer. I know this is very sparse information, but am unsure about how to debug this problem further. Any hints would be greatly appreciated!

When defining the checker in flycheck-define-checker, the url of the project is set to https://github.com/alexmurray/clang-analyzer/. (line 218 of flycheck-clang-analyzer.el on my machine)

It should be changed to https://github.com/alexmurray/flycheck-clang-analyzer/

rtags appears to support retrieving compilation arguments using elisp - rtags-compilation-flags and current project rtags-current-project so should be able to use it as a backend alongside irony.

I'd say this is good enough to be added to Flycheck itself. :)

Do you want to give that a try?

flycheck-clang-analyzer--rtags-get-compile-options uses rtags-compilation-flags to get the compilation flags and then filters them through flycheck-clang-analyzer--valid-compilation-flag-p.

Depending on how you look at it, the implementation of flycheck-clang-analyzer--valid-compilation-flag-p is either very naive, or rtags-compilation-flags doesn't do the right thing.

I have filed issue Andersbakken/rtags#1223 to see what RTags has to say about it, but I'll repeat some of that here.

Say you have:
clang++ -isystem /foo -iquote /bar -fsanitize=address,undefined -c -o my.o my.cpp
then rtags-compilation-flags will give you:

clang++
-isystem
/foo
-iquote
/bar
-fsanitize=address,undefined
-c
-o
my.o
my.cpp

while flycheck-clang-analyzer--valid-compilation-flag-p seems to expect:

clang++
-isystem /foo
-iquote /bar
-fsanitize=address,undefined
-c
-o my.o
my.cpp

As RTags does it today, flycheck-clang-analyzer--valid-compilation-flag-p will remove /foo and /bar while leaving -isystem and -iquote as standalone flags. And it will remove -o, but leave the name of the output file. Needless to say that this then makes flycheck-clang-analyzer fail.

If RTags decides to change its output, then this problem will go away for newer versions.

If not (and for older version), perhaps flycheck-clang-analyzer--valid-compilation-flag-p could be made more forgiving? Perhaps rewriting it to be more of a filter function instead that removes -c and -o, taking into account that those entries may or may not contain a filename. And if not, that the next option may be a filename.

The function ccls--is-ccls-buffer has been removed in this commit. This causes the ccls backend to be reported as inactive and only the fallback solution will be used.

Hello,

I have been trying to include this package in my spacemacs config. I undertook the following steps:

• put flycheck-clang-analyzer in dotspacemacs-additional-packages
• add the config to dotspacemacs/user-config:

(use-package flycheck-clang-analyzer
  :ensure t
  :after flycheck
  :config (flycheck-clang-analyzer-setup))

However, when trying to select clang-analyzer as checker, an error occured:

Syntax checker in buffer hello_world.h in c++-mode:

  clang-analyzer
    - major mode: `c++-mode' supported
    - may enable: yes
    - predicate:  nil
    - executable: Found at /usr/bin/clang
    - Backend:    flycheck-clang

Flycheck cannot use this syntax checker for this buffer.

Flycheck Mode is enabled. Use SPC u C-c ! x to enable disabled checkers.

--------------------

Flycheck version: 32snapshot (package: 20190311.1422)
Emacs version:    26.1
System:           x86_64-pc-linux-gnu
Window system:    x

It would be very helpful if someone can shed some light on this issue. Thanks!

I am wondering if its possible to configure flycheck-clang-analyzer to pass arguments to clang to tell it to read compile_commands.json in the project root directory. Configuring static arguments seems straightforward, but I would ideally like to determine the project root directory on the fly (e.g. using projectile) and tell clang to look there for the compilation database. Any suggestions would be much appreciated.