Allow arbitrary commandline arguments for the clang checker

[sethfowler]

It'd be great if we could send arbitrary commandline arguments to clang. Right now there's flycheck-clang-warnings and flycheck-clang-include-path, but some codebases I work on need a more complicated set of flags or else I get spurious warnings. I can easily write elisp to produce the appropriate flags for a file, but there doesn't seem to be any way for me to pass that information to flycheck. Ideally, flycheck-clang-arguments or something along those lines would exist and would get appended to the other clang arguments.

[swsnr]

@sethfowler I won't allow arbitrary command lines for syntax checkers. In many cases, error parsing depends on a given set of flags, and would break if arbitrary flags were passed.

Tell me, which concrete flags you need, and I'll add corresponding options.

[sethfowler]

Off hand I know I'd need -D, -include, and --std=. I'll take a look tomorrow and see if there are any other important ones.

[swsnr]

I'll add these.

[sethfowler]

Thanks so much!

I looked over the compiler arguments used by our code and I think the only one not listed above that could affect flycheck results is -fno-rtti, since it will warn if you try to use dynamic_cast or typeid. This one is not as big a deal as the others, though, in that not having the others will cause warnings for correct code, while lacking -fno-rtti will just cause flycheck to fail to print warnings for some incorrect code.

[swsnr]

@sethfowler Do you really need -include?! What's the point of that option? Why would you want to include a file via compiler option instead of #include?

[swsnr]

@sethfowler Do you have some example code to trigger RTTI warnings with -fno-rtti? I failed to get any warnings for use of dynamic_cast or typeid, even with -fno-rtti.

[sethfowler]

@lunaryorn Yes, I need -include. It may seem pointless but it is nonetheless used in large C++ projects, including the one I work on, and it's not practical to change their build system just to support flycheck. I'm not a huge fan of it either.

[sethfowler]

@lunaryorn I'm surprised, but you're right: clang does not warn about this. I remembered GCC warning about this, but in fact it gives an error rather than warning:

> g++ -fno-rtti -Wall foo.cpp
foo.cpp: In function ‘int main(int, char**)’:
foo.cpp:6: error: ‘dynamic_cast’ not permitted with -fno-rtti

[swsnr]

@sethfowler I meant no offense. I was just really surprised, for I never saw this option. In fact I didn't even know it existed. Just being curious: Do you have a concrete example for how this option is being used?

Of course, if you need it, I'll add it.

I'll also add -fno-rtti, despite the lack of warnings/errors. Probably this gets fixed some day.

[swsnr]

I have added the requested options:

• flycheck-clang-no-rtti for -fno-rtti,
• flycheck-clang-language-standard for -std=,
• flycheck-clang-includes for -include, and
• flycheck-clang-definitions for -D.

The first is a simple boolean flag, the second a string with the name of the standard, and the last two are lists of strings, where each string is a include file or definition respectively.

If anything is unclear, please read the docstrings of these variables, and do not hesitate to ask further questions.

[sethfowler]

@lunaryorn Sorry, tone is tricky on the internet, and I can see now that I didn't do a good job of saying what I was trying to say above. No offense meant or taken. =)

Gecko (which is the project I mentioned that uses -include) has a configure script that generates a file which contains a large set of #define's. It does this so that it doesn't have to pass huge numbers of -D arguments to every compiler invocation. That's where -include comes in.

I really appreciate you adding all of these options! This is fantastic; I look forward to using them.

[swsnr]

Gecko (which is the project I mentioned that uses -include) has a configure script that generates a file which contains a large set of #define's. It does this so that it doesn't have to pass huge numbers of -D arguments to every compiler invocation. That's where -include comes in.

Thanks for your explanation. I already figured that it would be used for this purpose, and it sounds reasonable.

I have never seen this before, though. Hitherto I thought the typical way to deal with a lot of configuration #defines was to generate a config.h during ./configure and explicitly include that header in all files that need access to the build configuration.

I really appreciate you adding all of these options! This is fantastic; I look forward to using them.

You are welcome. Please do not hesitate to open further issues, should you need more options for Clang.