Flycheck-rtags usage in single entry project

[mattt-b]

I thought for sure I used to use rtags like this, but I've spent hours trying to get it to work again to no avail. Simple example:
main.c

#include "foo.c"
int main(void) {
    foo_func();
    return 0;
}

foo.c

void foo_func(void) {
    i++;
}

compile_commands.json

[
    {
        "arguments": [
            "cc",
            "-c",
            "-o",
            "main",
            "main.c"
        ],
        "directory": "/path/to/test",
        "file": "main.c"
    }
]

Two issues I have that I thought I used to not have

1. rtags-diagnostics won't populate errors in the other files unless I open the file in emacs (so it's not following the includes).
2. flycheck-list-errors/flycheck-next-error/etc only work for the current buffer (even when rtags-diagnostics shows errors in other files). I thought I used to have it do error highlighting on line 1 to indicate an error in another file, or even better, highlighted the correct #include file. And would cycle through all errors in the project instead of just the current file.

Does ^ this behavior work with rtags-flycheck somehow, or am I misremembering?

[casch-at]

1. Not quite sure about that @Andersbakken
2. That was always the case, flycheck operates on a file to file bases. Not sure, if flycheck can be used to operate on many files. Do you know a flycheck back-end which does this?

[mattt-b]

2. That was always the case, flycheck operates on a file to file bases. Not sure, if flycheck can be used to operate on many files. Do you know a flycheck back-end which does this?

I know the Go back-end does. The ones I've written (poorly) do as well. Some others do as well I'm sure, but I don't have my main dev machine for a while. By default if you return flycheck errors for other files it'll highlight line #1, still show the errors in list, and cycle to them. For some reason I was so sure that flycheck-rtags did this I abandoned my own hacky implementation for it.

Anyway, sorry to bother you. Guess I was misremembering. Rtags is phenomenal, I'll just swap out the flycheck integration for a hackier version or try to modify yours for my own desires if I can.

[casch-at]

I know the Go back-end does. The ones I've written (poorly) do as well. Some others do as well I'm sure, but I don't have my main dev machine for a while. By default if you return flycheck errors for other files it'll highlight line #1, still show the errors in list, and cycle to them. For some reason I was so sure that flycheck-rtags did this I abandoned my own hacky implementation for it.

Cool, if that's possible I'll add support to the flycheck-rtags back-end. Thanks!

[mattt-b]

Rtags seems to only populate diagnostics for the current buffer. Given the age of this project and that no one seems to have cared about this before, I worry that this is way more work than it's worth

[casch-at]

I had a quick look in flycheck-rtags.el, and should be straight forward to add support for it. The functions https://github.com/Andersbakken/rtags/blob/master/src/flycheck-rtags.el#L72 and https://github.com/Andersbakken/rtags/blob/master/src/flycheck-rtags.el#L101 need to be adopted. The currently operate on the current-buffer, instead of the entire rtags-diagnostics buffer content. But I will probably add a switch for it. So the user can decide whether to get flycheck errors for the current buffer only, or for the hole project.

Rtags seems to only populate diagnostics for the current buffer. Given the age of this project and that no one seems to have cared about this before, I worry that this is way more work than it's worth

That actually looks pretty easy.

[casch-at]

@mattt-b I added an initial implementation for that. Though, I think it would be a good idea to add the project relative filename to the error message, when to errors should be shown for all open buffers. Can you test it too, thanks!

2e4155e

[casch-at]

@mattt-b Unfortunately flycheck wasn't designed to operate on multiple buffers at the same time. Therefore, I'll not add this feature.