4

I am working on a c++ project utilizing Qt. I have enabled syntastic to check headers through my vimrc, and its checkers (gcc, clang_check, and clang_tidy) all complain about the same thing in my project: they're unable to find a particular header file.

The header file in question is 'QtCore/qconfig-64.h'. And they are correct that this file does not exist. The problem is that this file should not be loaded into the project as it is a 32-bit project. 'QtCore/qconfig.h' has a preprocessor direction informing the project what to include: 

#if __WORDSIZE == 32
#include "QtCore/qconfig-32.h"
#elif __WORDSIZE == 64
#include "QtCore/qconfig-64.h" 
#else
#error "unexpected value for __WORDSIZE macro"
#endif

Is there any proper solution to get syntastic to recognize the preprocessor directive choosing which header file to include? If not, what other work arounds might be available to silence these errors while minimizing loss of utility?

Christian Gibbons
  • 4,272
  • 1
  • 16
  • 29
  • 3
    Read `:h syntastic-debug` and `:h syntastic-cpp-gcc`, and try to make syntastic run the same command line used to compile your files. This can be a pain in the rear because of how Vim and syntastic work, but it's the only meaningful approach. – Sato Katsura Aug 26 '17 at 08:18
  • @SatoKatsura : I will look into the syntastic debug info the next opportunity I get. As for whether syntastic is running the same command as my compiler, I directed syntastic to use the .clang_complete file generated by the cc_args.py script that comes with the plugin. I feel it is--if not exact--close enough to the same command for most practical purposes. My best conjecture with my current information is that the way Syntastic searches code for include statements either does not take #if statements into account, or does not take environment variables into account that would apply to them. – Christian Gibbons Aug 28 '17 at 05:25
  • Syntastic doesn't care about `#if`s, or about the contents of your files. What syntastic does is run linters, in this case `gcc`, `clang-check`, and `clang-tidy` (on a side note: `clang-tidy` does everything `clang-check` does, so you don't need to run both). If you don't provide all relevant `-Dfoo=bar` to these linters you'll get useless errors, and / or they'll bail out without checking anything. Unless you're unusually good at ESP, this is where `:h syntastic-debug` comes into the picture. – Sato Katsura Aug 28 '17 at 12:41
  • Okay, I see it now. Seems that `clang_complete`'s cc_args.py ignores a few types of compiler flags. I had noticed it left off `-O2` which resulted in warnings related to _FORTIFY_SOURCE. Seems it also left off the `-m32` flag informing on the program's 32-bit nature. On that note, passing these flags into `syntastic_cpp_compiler_options` fixes the issue for `gcc`, however `clang_check` and `clang_tidy` do not seem to have their `mkprg` commands altered by this var. That issue, however, probably belongs in its own question (if not already covered) or perhaps a bug report. – Christian Gibbons Aug 28 '17 at 14:06
  • You might consider reading the manual (`:h syntastic-c-clang_tidy` etc.) before filing a bug report. _shrug_ – Sato Katsura Aug 28 '17 at 14:10
  • I certainly intend to. Don't wish to waste the time of the developers chasing down a potential red herring without investigating the issue first. – Christian Gibbons Aug 28 '17 at 14:12

1 Answers1

-3

See :h 'syntastic_quiet_messages', try this for your case

let g:syntastic_c_gcc_quiet_messages = {
        \ "regex": ['\mQtCore/qconfig-64\.h']
        \}

Note: QtCore/qconfig-64\.h can be expanded to full error message to try to avoid missing other messages with same string

leaf
  • 1,624
  • 11
  • 16
  • 2
    Silencing the compiler about missing include files is probably the worst way to deal with this. Among other things, `gcc` will skip any further errors. – Sato Katsura Aug 26 '17 at 08:14
  • It's a potential problem. Regex can be expanded to try to avoid this. – leaf Aug 28 '17 at 02:05
  • 1
    A missing header is a fatal error for `gcc`, it will stop running after that. `g:syntastic_c_gcc_quiet_messages` does what it says, it quiets some messages. It won't convince `gcc` to go restart parsing after detecting a missing header. – Sato Katsura Aug 28 '17 at 12:32