From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 116448 invoked by alias); 25 Oct 2017 04:02:52 -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 116420 invoked by uid 89); 25 Oct 2017 04:02:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=H*UA:6.1, H*u:6.1, site X-HELO: aserp1040.oracle.com Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com) (141.146.126.69) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 25 Oct 2017 04:02:49 +0000 Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v9P42ks4003410 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 25 Oct 2017 04:02:46 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v9P42k7F027958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 25 Oct 2017 04:02:46 GMT Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v9P42jcP021549; Wed, 25 Oct 2017 04:02:45 GMT Received: from [10.159.158.181] (/10.159.158.181) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 24 Oct 2017 21:02:45 -0700 Subject: Re: [C++ Patch] PR 80955 (Macros expanded in definition of user-defined literals) To: Jason Merrill Cc: Nathan Sidwell , gcc-patches List References: <6bd671aa-97cf-1dcc-ca90-5948ab533113@oracle.com> <58ca43f6-e0a6-0419-8e46-cbb6b78f845c@acm.org> <8d9f3e13-9b65-da73-499c-05e569eef046@oracle.com> <4e6e0a54-cf50-8944-a1bd-18f11d8b506c@oracle.com> From: Mukesh Kapoor Message-ID: Date: Wed, 25 Oct 2017 05:48:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2017-10/txt/msg01786.txt.bz2 On 10/24/2017 7:05 AM, Jason Merrill wrote: > On Fri, Oct 20, 2017 at 3:52 PM, Mukesh Kapoor wrote: >> On 10/20/2017 11:00 AM, Mukesh Kapoor wrote: >>> On 10/20/2017 10:45 AM, Nathan Sidwell wrote: >>>> On 10/20/2017 12:37 PM, Mukesh Kapoor wrote: >>>>> This patch fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80955. >>>>> Handle user-defined literals correctly in lex_string(). An empty string >>>>> followed by an identifier is >>>>> a valid user-defined literal. Don't issue a warning for this case. >>>> a) why do we trigger on the definition of the operator function, and not >>>> on the use site? >>> Actually, the current compiler issues an error (incorrectly) at both >>> places: at the definition as well as at its use. >>> >>>> b) Why is the empty string special cased? Doesn't the same logic apply >>>> to: >>>> >>>> int operator "bob"_zero (const char *, size_t) { return 0;} >>> This is not a valid user-defined literal and is already reported as an >>> error by the compiler. After my changes it's still reported as an error. >>> The empty string immediately followed by an identifier is a special case >>> because it's a valid user-defined literal in C++. ""_zero is a valid >>> user-defined literal. >> Sorry, I used incorrect terminology here. An empty string immediately >> followed by an identifier is a valid name for a literal operator; ""_zero is >> a valid name for a literal operator. > Yes, and indeed "bob"_zero isn't. But it would be fine for the > testcase to return "bob"_zero, a valid user-defined string literal > which calls operator ""_zero, and that will still break after your > patch. > > It seems like we need to handle this error recovery in the front end, > where we can look to see if there's a matching operator, rather than > in libcpp. Thanks for pointing this out. Checking in the front end will be difficult because the front end gets tokens after macro expansion. I think the difficulty of fixing this bug comes because of the requirement to maintain backward compatibility with the option -Wliteral-suffix for -std=c++11. Mukesh > > Jason