Thanks for your reply and your explanations and sorry for my late reply. I
am a colleague of Martin Richtarsky, and actually I am the one who asked
Martin to report this bug.
First, I would like to give you some more background. We have implemented
our own compile cluster for several reasons (better performance, higher
reliability, integrated distributed object files cache, remote cluster
administration, support for Windows builds, etc.). However, in order to
provide these cluster features (the cache features in particular and support
for Windows), the preprocessing step is absolutely mandatory!
I would like to add two thoughts regarding this bug report:
1) One might discuss, whether the compiler should emit or skip warnings, if
these warnings only occur after macro expansion. My personal opinion is,
that I would like to see really all pieces of code that cause warnings, even
if these warnings only occur after macro expansion. When implementing or
using macros, I would like to really know, if these macros are
"warning-free". However, experience shows that discussions about such topics
quickly turn out to be "religious discussions", some love it, some hate it,
and the best way is to satisfy both sides by giving the freedom of choice.
Therefore I guess, a great clang feature would be to add a new compiler
option like "-Wstrict-macro-warnings" or similar, that controls the
compiler's behavior in that case.
2) However, warning behavior after macro expansion isn't really the topic of
this bug report. The key topic here is, that compiling a CPP file directly
gives different warnings than first preprocessing CPP file and then
compiling preprocessed file. I've been working with many different C++
compilers, and I cannot remember any compiler behaving that way. All
compilers, I am aware of, do NOT emit different warnings/errors, when
compiling directly vs. compiling preprocessed file. Furthermore, C++
standard only talks about "preprocessing tokens", which indicates that
preprocessing is a purely lexical operation and shouldn't have any impact on
compiler semantics. I couldn't find any hint in C++ standard indicating that
preprocessing would potentially modify compiler semantics. Therefore, I
would highly appreciate, if you could find a way to fix this issue. If the
suggestion in (1) can be easily implemented (additional compiler flag for
controlling the behavior), that would probably be a fix for the topic
discussed in (2).
Thanks + best regards,