[RFA] statement before variable declaration in cp_parser_initializer_list.

Hello,

I happened to notice a warning while compiling GCC, and it seemed
like an easy fix...

gcc/cp/ChangeLog:

        * parser.c (cp_parser_initializer_list): Move declaration
        of variable non_const to start of lexical block.

Tested against x86_64-linux, no regression.
OK to commit? (obvious?)

Thanks,

On Thu, Jan 3, 2013 at 1:30 PM, Joel Brobecker <brobecker@adacore.com> wrote:
> Hello,
>
> I happened to notice a warning while compiling GCC, and it seemed
> like an easy fix...
>
> gcc/cp/ChangeLog:
>
>         * parser.c (cp_parser_initializer_list): Move declaration
>         of variable non_const to start of lexical block.
>
> Tested against x86_64-linux, no regression.
> OK to commit? (obvious?)

Hmm?  We compile with a C++ compiler where this is perfectly valid ...

Richard.

> Thanks,
> --
> Joel
>
> ---
>  gcc/cp/parser.c |    3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
> index 3dc2ec6..61d93f8 100644
> --- a/gcc/cp/parser.c
> +++ b/gcc/cp/parser.c
> @@ -17932,9 +17932,10 @@ cp_parser_initializer_list (cp_parser* parser, bool* non_constant_p)
>                && cp_lexer_next_token_is (parser->lexer, CPP_OPEN_SQUARE))
>         {
>           /* In C++11, [ could start a lambda-introducer.  */
> +         bool non_const = false;
> +
>           cp_parser_parse_tentatively (parser);
>           cp_lexer_consume_token (parser->lexer);
> -         bool non_const = false;
>           designator = cp_parser_constant_expression (parser, true, &non_const);
>           cp_parser_require (parser, CPP_CLOSE_SQUARE, RT_CLOSE_SQUARE);
>           cp_parser_require (parser, CPP_EQ, RT_EQ);
> --
> 1.7.0.4
>

> > Tested against x86_64-linux, no regression.
> > OK to commit? (obvious?)
> 
> Hmm?  We compile with a C++ compiler where this is perfectly valid ...

I was compiling with GCC 4.7 where it gave me a warning... I don't know
much about C++ anymore, so I didn't know. Oh well!

> Hmm?  We compile with a C++ compiler where this is perfectly valid ...

Not on earlier branches though, e.g. the 4.7 branch.  So I would install it 
everywhere to avoid gratuitous differences.

On Thu, Jan 3, 2013 at 1:37 PM, Joel Brobecker <brobecker@adacore.com> wrote:
>> > Tested against x86_64-linux, no regression.
>> > OK to commit? (obvious?)
>>
>> Hmm?  We compile with a C++ compiler where this is perfectly valid ...
>
> I was compiling with GCC 4.7 where it gave me a warning... I don't know
> much about C++ anymore, so I didn't know. Oh well!

Ah, for the 4.7 branch yes.

Thanks,
Richard.

> --
> Joel

Hi Richard,

> >> Hmm?  We compile with a C++ compiler where this is perfectly valid ...
> >
> > I was compiling with GCC 4.7 where it gave me a warning... I don't know
> > much about C++ anymore, so I didn't know. Oh well!
> 
> Ah, for the 4.7 branch yes.

Eric Botcazou asked that we have the same code for both 4.7 and HEAD.
Would it be OK to apply it to both? It's not really strictly
necessary for the HEAD, but I don't see it as being harmful either.

Thank you!

On Tue, Jan 8, 2013 at 12:37 PM, Joel Brobecker <brobecker@adacore.com> wrote:
> Hi Richard,
>
>> >> Hmm?  We compile with a C++ compiler where this is perfectly valid ...
>> >
>> > I was compiling with GCC 4.7 where it gave me a warning... I don't know
>> > much about C++ anymore, so I didn't know. Oh well!
>>
>> Ah, for the 4.7 branch yes.
>
> Eric Botcazou asked that we have the same code for both 4.7 and HEAD.
> Would it be OK to apply it to both? It's not really strictly
> necessary for the HEAD, but I don't see it as being harmful either.

Sure.

Richard.

> Thank you!
> --
> Joel

> > Eric Botcazou asked that we have the same code for both 4.7 and HEAD.
> > Would it be OK to apply it to both? It's not really strictly
> > necessary for the HEAD, but I don't see it as being harmful either.
> 
> Sure.

Thank you! Now checked in.