[patch] Add -CC option to cpplib to save comments in macros

[Neil Booth]

Hi Jason!

Jason R Thorpe wrote:-

> Folks...
> 
> The following patch adds a -CC option to the pre-processor which
> is like -C (save comments), but also copies comments to the output
> where macros are expanded.  This is primarily to support lint.

I tried this in the same way for -C in the 3.1 series (I'd like your
-CC to be the behaviour of -C - I'm sure we discussed this 8^)), but I
had the same issues that your patch does not address either.  I only
removed the feature a few months ago.

I don't know the right month, but the last discussion about this was
probably around October.  You might want to search the mailing list
archives, and / or check out testsuite/gcc.dg/cpp/cmdline-C{,2}.c.

> 	* cppinit.c (cpp_create_reader): Initialize
> 	discard_comments_in_macro_exp.
> 	(COMMAND_LINE_OPTIONS): Add "-CC" option.
> 	(cpp_handle_option) Handle "-CC" option.
> 	* cpplib.c (_cpp_handle_directive): If processing
> 	a `#define' directive and discard_comments_in_macro_exp
> 	is false, re-enable saving of comments.
> 	* cpplib.h (struct cpp_options): Add discard_comments_in_macro_exp
> 	member.
> 	* doc/cpp.texi: Document the -CC option.

The issues I have are:

1) C++ comments are also preserved, which can be an issue:

   #define foo // comment
   foo bar

which would comment out bar.  People did hit this and complain; they
wanted to be able to re-compile the output (which -C currently
supports).  We could scrap C++ comments in macros, or to convert them
to C comments.  The latter is best IMO.

2) You do nothing to lose comments in #if statements.

   #define foo 2 /* Some number */
   #if foo > 1

confuses the expression evaluator.

3) I _think_ there might be something else, but I've forgotten it 8-)
   Ah, yes.  I think it messes up macro expansion if you have

   #define foo() some expansion
   foo /**/ ()

   [Pause...] Hmm, we don't get this right even now.

In view of this, and since fixing issue 3 (which is a real pig - trust
me) without unduly hurting run-time performance is not at all trivial
IIRC, I'd rather leave this to 3.2 since 3.1 is really in a feature
freeze anyway.

Sound reasonable?

Neil.