On 06/08/2013 09:34 AM, Andrew Sutton wrote:
I think I previously put constraint_info in lang_decl_min, right next to template_info no less. It was easy to manage there, and initialized as part of build_template_decl. But this obviously doesn't work for partial specializations unless they get template_decls.
Right. And we would want it to be specific to template_decls, not all decls that use lang_decl_min.
I'd be okay committing the current design with the caveat that it may need to be rewritten in the not-so-distant future. I've already written the other other way two or three times, so I'm familiar with those changes.
Yeah, that sounds fine.
On the topic of logic.cc, I'm plan on rewriting this module to use a set instead of lists. There will be some pretty substantial changes to the internal interfaces. Would it be reasonable to commit this now (since it works correctly), and plan to rewrite it in the near future?
OK.
I think I see where the problem is. cp_parser_requires_clause is parsed non-optionally in a requires expression, but that's not included in the patch. I factored out the explicit parsing (hence the assertion) from the optional parsing.
The two situations seem pretty similar; you don't decide you're parsing a requires expression until you see the keyword either, right?
The usual pattern in the parser is for a function to try to parse a particular construct and then return NULL_TREE if we're looking at something else; it seems most straightforward to do that in this case as well.
What is the main entry point to overload resolution?
Perhaps finish_call_expr is what you want. Jason
