On 06/04/2012 10:46 PM, Jason Merrill wrote:
On 06/04/2012 04:12 PM, Florian Weimer wrote:
This doesn't make sense to me. parser-integral_constant_expression_p
should always be true at this point if you're moving the restore later
(which also seems unnecessary).
I think
On 06/05/2012 11:19 AM, Florian Weimer wrote:
True. But if we want cascading errors, cp_parser_constant_expression
really cannot return error_mark_node, so this approach is a dead end.
(For example, build_enumerator replaces error_mark_node in the
enumeration value with nothing, i.e., the next
On Tue, Jun 5, 2012 at 12:05 PM, Jason Merrill ja...@redhat.com wrote:
In the operator new case, the non-constant expression error followed by the
VLA warning is not as helpful, as the latter ignores the former. Perhaps the
right way to deal with this is to allow non-constant expressions in
Without this change, cp_parser_constant_expression reports errors in
C++11 mode, but does not provide any indication to callers, which
continue processing and produce misleading errors.
The changes to check_bitfield_decl and build_enumerator are required for
identical error report in C++11
On 06/04/2012 06:36 AM, Florian Weimer wrote:
(Sorry if Thunderbird has garbled the changelog entries.)
I add the ChangeLog to the top of the patch to avoid this. :)
- if (TREE_CODE (w) != INTEGER_CST)
+ if (w == error_mark_node)
+ ; /* Continue with error processing below.
On 06/04/2012 08:40 PM, Jason Merrill wrote:
On 06/04/2012 06:36 AM, Florian Weimer wrote:
(Sorry if Thunderbird has garbled the changelog entries.)
I add the ChangeLog to the top of the patch to avoid this. :)
Good idea.
- if (TREE_CODE (w) != INTEGER_CST)
+ if (w == error_mark_node)
+ ;
On 06/04/2012 04:12 PM, Florian Weimer wrote:
This doesn't make sense to me. parser-integral_constant_expression_p
should always be true at this point if you're moving the restore later
(which also seems unnecessary).
I think parser-integral_constant_expression_p reflects the result of
the
