On 06/05/2013 11:45 AM, Paolo Carlini wrote:
Now, something else I noticed a few days ago is that for C-style casts
things work fine in any case: the difference being that in that case we
set parser->in_type_id_in_expr_p to true, something we don't do for
static_cast (and the other C++ casts) in
Hi,
On 06/05/2013 04:19 PM, Jason Merrill wrote:
On 06/05/2013 09:19 AM, Jason Merrill wrote:
In any case, the commit doesn't seem like the problem.
Oh, I see, of course it is. The problem is that it commits to all
levels, so that if we happen to be in a nested tentative parse we
can't com
On 06/05/2013 09:19 AM, Jason Merrill wrote:
In any case, the commit doesn't seem like the problem.
Oh, I see, of course it is. The problem is that it commits to all
levels, so that if we happen to be in a nested tentative parse we can't
commit to the inner one without committing to the oute
.. true that my first try didn't fix this non-variadic variant, because
we have a declarator and again we hit the commit:
struct foo
{
template
operator decltype(static_cast(0)) () const;
};
Paolo.
On 06/05/2013 09:07 AM, Paolo Carlini wrote:
Hi,
On 06/05/2013 02:53 PM, Jason Merrill wrote:
On 06/04/2013 08:34 PM, Paolo Carlini wrote:
/* After seeing a decl-specifier-seq, if the next token is not a
- "(", there is no possibility that the code is a valid
+ "(" nor '...', t
Hi,
On 06/05/2013 02:53 PM, Jason Merrill wrote:
On 06/04/2013 08:34 PM, Paolo Carlini wrote:
/* After seeing a decl-specifier-seq, if the next token is not a
- "(", there is no possibility that the code is a valid
+ "(" nor '...', there is no possibility that the code is a vali
On 06/04/2013 08:34 PM, Paolo Carlini wrote:
/* After seeing a decl-specifier-seq, if the next token is not a
- "(", there is no possibility that the code is a valid
+ "(" nor '...', there is no possibility that the code is a valid
expression. Therefore, if parsing tentati
Hi,
this ICE on valid happens in the cp_parser_abort_tentative_parse called
at the end of cp_parser_decltype_expr. I started seriously looking into
it when I noticed that a variant of the testcase not using variadic
templates is fine, thus I concentrated on
cp_parser_parameter_declaration and
