Re: [c++-concepts] code review

[Jason Merrill <jason@redhat.com>]

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