------- Comment #9 from dodji at gcc dot gnu dot org 2008-08-01 13:32 -------
Created an attachment (id=15991)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15991&action=view)
updated patch
> - the error message we give in this case is pretty poor. Here we have an
>empty initializer, but the error message we get back is "void value not ignored
>as it ought to be", which really doesn't tell us much of anything about the
>problem.
I agree. Though I think addressing that should be best done in another bug
that we can open straight away when we close this one, if you agree.
>The real issue here is that the statement expression has no return
>value, so we should say as such. This same problem can occur with non-empty
>statement expressions whose last statement does not produce a value, right?
>We
>should test this case, too.
I think the problem (g++ not issuing any warning)
is due to the tsubsted initializer yielding NULL.
An expression made of a statement list which last statement
does not return any value whould be tsubsted to a statement list
of type VOID_TYPE, I believe.
For instance the current g++ 4.3.0 issues the warning for the
following code snippet:
----
void foo ();
void bar ();
void
func ()
{
int y = 0;
int i = ({ foo (); if (y) bar (); });
}
----
/home/dodji/devel/src/test.cc: In function 'void func()':
/home/dodji/devel/src/test.cc:8: error: void value not ignored as it ought to
be
>
> - since the statement-expression is obviously empty, can we produce this
>error message at template definition time, rather than waiting until
>instantiation time? (If the answer isn't a quick "yes", don't worry about it;
>I'll eventually be going through the initialization bits to check more of them
>at template definition time anyway.)
Yes, that would be handy. Though here again, I think we should be opening
another bug to track that.
>
> - is_pack_expansion_node_p is a pretty general name for a function that is
>specific to initializer lists (in general, a TREE_LIST with a pack expansion in
>its TREE_VALUE isn't necessarily an "expansion node"). I suggest calling this
>"initializer_is_pack_expansion_p".
>
Right. This updated patch addresses that.
> - Please put some braces inside the if (init && !t) block. Omitting the
>braces for "then" and "else" is okay for small one-liner bodies, but shouldn't
>be done when there are if-elses nested inside.
Fixed in this udpated patch.
>
> - parse/empty-statement.C is a strange place to put this check, which deals
>with template instantiation. Perhaps call it template/empty-init-statement.C?
Yup. Fixed.
>
> - In the top of the testcase, "PR c++/P36408" should be "PR c++/36408"
Fixed as well.
Thank you for your comments.
--
dodji at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #15989|0 |1
is obsolete| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36408
