[cfe-dev] Warnings are different on preprocessed file

[Lubos Lunak]

On Thursday 13 of March 2014, Richtarsky, Martin wrote:
> >http://llvm.org/viewvc/llvm-project?view=revision&revision=156861
> >
> > That's not the only case when Clang suppresses a warning for something
> > coming from a macro, so a separate preprocessing step results in a
> > warning that wouldn't be otherwise reported. On the other hand, why would
> > one actually need a separate preprocessing step for normal usage in
> > practice anyway.
>
> Thanks for the info. I agree that preprocessing is usually not done
> separately, but distributed compile clusters like icecream rely on it
> (preprocess locally, compile remotely).

 They actually don't, icecream uses -frewrite-includes and does "normal" 
compile on the remote host if the version is recent enough ('icecc --help' 
should mention ICECC_CLANG_REMOTE_CPP, v1.0 should do, although the newer 
icecream and clang the better, given that even current clang still has 
minor -frewrite-include bugs pending). My current icecream and clang builds 
manage to have identical stderr output in the local and remote case for 
anything I've tried.

 If you use ccache and have similar problems because of preprocessing, use 
CCACHE_CPP2=1.

> So it would be great to have consistent warning behavior. I don't
> want to disable the warning, are there any other workarounds?

 I don't think there's any other than not using a separate preprocessing step. 
I was looking into that when making icecream work well with clang, and it's 
pretty much a lost fight. Even if you managed to get all the warnings right, 
which is questionable if that's possible, you still would have problems e.g. 
with caret diagnostics, as they would report preprocessed input in messages. 
That could be worked around by using linemarks and reading the original 
source file (as gcc-4.8+ does), but that doesn't work with the remote 
icecream case (to-be-v1.1 icecream "supports" gcc caret diagnostics by 
compiling locally again if it detects the need).

 So if you still have valid use case for separate preprocessing step, I think 
a better chance is with finding a workaround that avoids that.

-- 
 Lubos Lunak