From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32498 invoked by alias); 11 Jun 2013 13:45:42 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 32487 invoked by uid 89); 11 Jun 2013 13:45:41 -0000 X-Spam-SWARE-Status: No, score=-3.7 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,SPF_PASS autolearn=ham version=3.3.1 Received: from mail-ve0-f174.google.com (HELO mail-ve0-f174.google.com) (209.85.128.174) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 11 Jun 2013 13:45:39 +0000 Received: by mail-ve0-f174.google.com with SMTP id oz10so5780968veb.33 for ; Tue, 11 Jun 2013 06:45:37 -0700 (PDT) X-Received: by 10.52.170.19 with SMTP id ai19mr6781642vdc.25.1370958337774; Tue, 11 Jun 2013 06:45:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.188.201 with HTTP; Tue, 11 Jun 2013 06:45:06 -0700 (PDT) In-Reply-To: <51B62961.1080409@redhat.com> References: <51B0B0ED.5090508@redhat.com> <51B0F122.6020301@redhat.com> <51B62961.1080409@redhat.com> From: Andrew Sutton Date: Tue, 11 Jun 2013 13:45:00 -0000 Message-ID: Subject: Re: [c++-concepts] code review To: Jason Merrill Cc: Gabriel Dos Reis , gcc-patches@gcc.gnu.org Content-Type: text/plain; charset=ISO-8859-1 X-SW-Source: 2013-06/txt/msg00580.txt.bz2 >> 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'll have to check. I can't remember off the top of my head if non-template member functions have a corresponding template_decl. I think they do. auto declarations will also get constraints in the future. >> 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 was experimenting with this over the weekend. I'm just going to rewrite it now, but without the optimizations I alluded to earlier. They didn't pan out the way I'd have liked. >> 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. Yes, but I wasn't testing for the keyword prior to the call to cp_parser_requires_clause_opt. That's not quite true, I was in for member functions, but that was an oversight. Changing to test for requires won't be hard. >> What is the main entry point to overload resolution? > > > Perhaps finish_call_expr is what you want. After investigating, neither call_expr nor resolve_nondeduced_context do what I need. I need a resolution of a call expression that does not return overload sets, especially in the case where the initial call expression is already dependent. resolve_nondeduced_context looks like a good candidate to extend, but I hesitate to modify since it's used in a number of different places, and winnowing the overload set may not be appropriate in those contexts.