[PATCH] PR15614 : -frewrite-includes causes -Wunused-macros false positives
l.lunak at centrum.cz
Wed Nov 27 05:39:22 PST 2013
On Tuesday 30 of July 2013, Eli Friedman wrote:
> On Sun, Jul 28, 2013 at 2:50 AM, Lubos Lunak <l.lunak at suse.cz> wrote:
> > On Monday 01 of July 2013, Eli Friedman wrote:
> >> On Sun, Jun 30, 2013 at 12:01 AM, Lubos Lunak <l.lunak at suse.cz> wrote:
> >> > Hello,
> >> >
> >> > could somebody please review and commit the atached patch for pr15610
> >> > (it needs the patch for pr15610 applied first in order to apply
> >> > cleanly). Thank you.
> >> >
> >> > Testcase?
> > Updated.
> This isn't really the right approach; it suppresses the warning when
> the -frewrite-includes flag is used, but not for the output of
> -frewrite-includes, which is what actually matters.
I disagree (or don't understand what you mean). The -frewrite-includes mode
is just some auxiliary step that actually has nothing to do with
preprocessing or compilation, those will be done when the resulting file will
be compiled. So it should not report or warn about any problem with the file,
except possible issues related to -frewrite-includes itself, as all those
reports will be handled when the result is passed to Clang again.
So if I understand the above correctly as you saying that -Wunused-macros
should be blocked for -frewrite-includes as well as for the follow-up
compilation, then this is not right, the warning should be there for the
actual compilation, just like it is there when compiling the original file
Updated patch that applies to current trunk attached. I've also modified it a
bit to show that the warnings are blocked for DisableMacroExpansion (since if
macros are not going to be expanded, they obviously will be unused, so maybe
it's clearer this way).
> See the thread "[PATCH] Correctly check for the main file in the
> presence of line markers".
I don't find that one relevant (except that with current trunk line markers
block -Wunused-macros completely, so this is now broken
with -frewrite-includes, but I'll submit a patch for that).
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2383 bytes
Desc: not available
More information about the cfe-commits