This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[C++ Patch / RFC] PR 29234


I'm having a look at this very old parsing issue. We reject things like:

struct S { void operator () (); };

void foo ()
  ( S()() );

because the parenthesized S()() triggers an hard error from groktypename as called at the end of cp_parser_type_id (called by cp_parser_cast_expression), about a function returning a function. Of course we have to parse it as an unary-expression.

I scratched my head for a while, but then I noticed that in cp_parser_cast_expression, a bit later the cp_parser_type_id call at issue, we are *already* using a cp_parser_tokens_start_cast_expression which helps use figuring out whether the tokens following the outer ')' make sense as a cast-expression. Using it a bit earlier to completely avoid calling cp_parser_type_id in the cases at issue, appears to work well, for a - negligeable in my opinion - additional computational cost.

Then, cp_parser_unary_expression is actually used. As part of that, cp_parser_postfix_expression looks for a compound-literal, but not in the robust way we are using elsewhere involving a cp_parser_skip_to_closing_parenthesis, but just using tentative parsing with cp_parser_type_id. Thus we are incurring again in the same issue. Parsing the compound-literal in the same way used elesewhere - thus looking for the '{' after the ')', solves the problem. In my personal opinion, again, the computational cost shouldn't be too high, because if we don't find '{' we completely avoid cp_parser_type_id.

Is this the kind of approach we want to pursue for this issue?

Tested x86_64-linux.



Attachment: patch_29234
Description: Text document

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]