False positives due to macro expansion

[abigailbunyan]

gcc, clang, etc. use -isystem to add an include path and to mark that no warnings should be generated for code within them. This also includes when macros are defined in system headers:

$ clang++ test.cpp -I include/ -Wold-style-cast
test.cpp:3:21: warning: use of old-style cast [-Wold-style-cast]
int main() { return FOO(0); }
                    ^~~~~~
include/test.h:1:17: note: expanded from macro 'FOO'
#define FOO(x) ((int)(x))
                ^    ~~~
$ clang++ test.cpp -isystem include/ -Wold-style-cast
$

In a large project I'm checking, use of Boost constructs such as the BOOST_FOREACH and BOOST_ASSERT macros generate a lot of bogus warnings.

[UnrealQuester]

This sounds like a good addition to oclint and would also solve things like #280.

Not sure if we can get the necessary information from clang but will see what I can do.

[ryuichis]

@UnrealQuester I have been wondering if a hack will do the trick. Even though at the time we have the AST layer from clang compiler, the marcos have been expanded already. However, I was thinking maybe we can take a look at the source file location of the problematic AST node to guess if it is from the same file or from a source location other than the current file. For the latter case, we would ignore them.

[daniel-beard]

The right way to do this would be using PPCallbacks and the MacroExpands method.
There was a talk about incorporating Preprocessor callbacks into AST Matchers this year at the LLVM conference: https://www.youtube.com/watch?v=EbUpI3V7QRw&feature=youtu.be
And the source from the talk: https://github.com/jefftrull/octothorpe

[UnrealQuester]

Thanks for the links, @daniel-beard!

Can we also find out if the macro definition is in a system header? We might want to warn for macros that the user has control over and ignore macros in third party libraries that the user likely can do nothing about.

[bart-kneepkens]

I would appreciate a solution as well. For the project I'm working on, I have macros defined that point to code inside the CocoaPods, that should be excluded by using the -e flag. This makes that there are lots of warnings for pods' code.

[jeppefrandsen]

+1

[ryuichis]

Renamed this issue to cover a broader problem due to macro expansion. Thanks @alistra for pointing it out. I am copying over his original comment to here:

Not exactly the same thing, as you may have non-system macros that experience this issue, as you always want to write macros defensively and you don't know when you will create extraneous parentheses, eg.

#define SUM(a,b) (a+b)

Will be ok for:

int a = SUM(6,7) * 4;

But will trigger the warning for:

int a = SUM(6,7);