preprocessor/5513: considers non-nested macro as nested one

preprocessor/5513: considers non-nested macro as nested one

[alexandervpetrov]

>Number:         5513
>Category:       preprocessor
>Synopsis:       considers non-nested macro as nested one
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Jan 28 05:06:01 PST 2002
>Closed-Date:
>Last-Modified:
>Originator:     Alexander Petrov
>Release:        gcc version 2.95.1 19990816 (release)
>Organization:
>Environment:
SunOS dionysus 5.7 Generic_106541-02 sun4u sparc SUNW,Ultra-5_10
>Description:
Preprocessor considers a non-nested macro as nested one:

# define A A_EXP B(
# define B() B_EXP A

A ) )

produces

A_EXP B_EXP A_EXP B(   )

and does not expand the last B macro. 

Like in PR 5498,
the expansion of macro B has terminated
by the time you get to the second ')', and therefore the 
second invocation of B is not nested, and B should be
re-expanded.

The handling of the last parenthesis in "A )" (in PR 5498) 
condtradicts with handling of the last parenthesis in "A ) )", 
so the expansion of at least one of these samples is incorrect.
>How-To-Repeat:
# define A A_EXP B(
# define B() B_EXP A

A ) )
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:

Re: preprocessor/5513: considers non-nested macro as nested one

[neil]

Synopsis: considers non-nested macro as nested one

State-Changed-From-To: open->closed
State-Changed-By: neil
State-Changed-When: Mon Jan 28 05:49:45 2002
State-Changed-Why:
    This is not a bug either.  I suggest you try
    
    www.comeaucomputing.com/tryitout
    
    with the -E option for independent verification before
    posting any more examples.  What software uses macros
    like this anyway?
    
    For PR/5498, the macro A has completely finished expanding
    and its expansion has been left (in order to get the ')')
    at the time that A comes up for re-expansion.  Hence it expands again.
    
    In this example (which is 5498 with an extra parenthesis)
    the original B is *still under expansion* when macro A
    is invoked, and so the token B in A's expansion
    is never considered for expansion, because that would
    be a nested expansion of B.  The opening parenthesis
    at the end of A is not even looked at when this
    decision to not expand B is made; B is still at
    the bottom of the macro stack.  See the difference?

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5513