This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: -traditional comment elimination (yuk...)
On Fri, May 12, 2000 at 08:40:14AM -0400, Dave Brolley wrote:
> Neil Booth wrote:
>
> > > Therefore, I see no particular reason why we can't just shut off -C
> > > when processing directives other than #define. That means the
> > > comments disappear, but the rest of the line's going to disappear too,
> > > so the comments are less than helpful.
> >
> > My feelings are moving towards shutting off -C for preprocessing
> > directives too.
>
> Yes -- this is the correct behaviour and, in fact, is the reason why
> comment pasting in macros in traditional preprocessors works.
>
> #define foobar 1
> #define cat(a,b) a/**/b
>
> In a traditional preprocessor, cat (foo,bar) produces 1 *everywhere* (open
> text and on directives) because the preprocessor removes the comment and
> then rescans the substituted text. This is an example where the two pass
> approach will still not be adequate since the expanded macro may never get
> re-lexed by the compiler.
>
> #if cat(foo,bar)
> this_code_should_get _compiled();
> #endif
Say Dave, would you mind writing up a series of tests for gcc.dg so we
can remember to get all this stuff right?
> > In the light of the above, if my understanding is correct, I am now
> > convinced of the right way forward, and it won't affect the current
> > lexer too much.
> >
> > 1) Just like a true K&R compiler, we make -traditional go through two
> > passes, via a temporary file just like Dave suggested. This means we
> > get the same tokenisation as a true K&R compiler would.
> >
> > 2) We need an extra flag TRAD_COMMENT for tokens to indicate a
> > traditional comment, to get the effect of not outputting whitespace.
>
> Why not just test for the -traditional option when deciding whether to
> replace a comment by a space?
This is what I've been arguing for all along, and in fact what my
line->token glue routine does (_cpp_scan_line). It gets most of the
traditional effects right, and the ones it gets wrong should be
fixable without much effort - except pasting together a comment start,
which I don't think is worth supporting.
Neil doesn't think this will work. I think this is because he's
confused about the way /**/ should be handled in traditional mode.
When not processing a #define, and you hit a comment, you discard the
comment, and then you *loop back and process the next token*. For
&/**/&, the second & will be seen with the first & in lookbehind
position, and they'll get pasted. It's exactly the same technique
that made \-newline work so simply.
When you are processing a #define, you have to return the two &'s as
separate tokens with no intervening whitespace. The #define handler
will then notice this and paste them together itself. (This is what
_cpp_can_paste_p is for, in the diff I sent you last night.) But it
gets a chance to notice pasted arguments.
zw