From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 130085 invoked by alias); 24 Oct 2017 14:05:32 -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 130069 invoked by uid 89); 24 Oct 2017 14:05:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=no version=3.3.2 spammy=recovery, site X-HELO: mail-it0-f67.google.com Received: from mail-it0-f67.google.com (HELO mail-it0-f67.google.com) (209.85.214.67) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 24 Oct 2017 14:05:30 +0000 Received: by mail-it0-f67.google.com with SMTP id r127so10150999itb.5 for ; Tue, 24 Oct 2017 07:05:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LmzYUwY1Lfgtae8/zI5oJw8oD44bUlTy2IRCWwHf00U=; b=slZB031BTefv3xcO+git7nh8zCAuudgb5pEWBT+vE1b/IZ61s0IXMuSVazNucPDIeA 2pUECaqaWDbKrVEuUxALuvtA0yULk0tHf+avHfqP06qDo8zkY/79LAjzcwDd4LGtnbF5 l9D5Y5rdeoybetKD8gS21IEDAk3AAhSPrL5Jm8fBfggNBC2zpqZ6H/3S+R/bF09Nuty6 /xKwC/I6N9ICmNj15HWo18QC5hWB/f9hxJJ5MLi3sGw5e1hHivCw2rz3P2oBupFfVVm0 rbKFEZ8au8LQPTzAoVXwGfw/Se9k5NkxZKZgQkdkkV/vitRl/Bdoowm8uLc1dXVNNqrA jPjw== X-Gm-Message-State: AMCzsaXIXqLwAvi87Q7nSQJp4Kc6eXJr2yTsGhSBhFUxTUsi0bWjU0bj KERPxeFn7HW2VNqyE3ZPPPItHzk10cmtjXZXe4UQbw== X-Google-Smtp-Source: ABhQp+RPPlHl2+AP3mtn90EmVAB6+PD69P3jEjP3hgwVMN+GXYlcnfOasCVfQCEeRqa00gbSFjhQSZsR6GrTvgx6qhk= X-Received: by 10.36.154.71 with SMTP id l68mr12422020ite.57.1508853928155; Tue, 24 Oct 2017 07:05:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.170.26 with HTTP; Tue, 24 Oct 2017 07:05:07 -0700 (PDT) In-Reply-To: <4e6e0a54-cf50-8944-a1bd-18f11d8b506c@oracle.com> 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: Jason Merrill Date: Tue, 24 Oct 2017 14:07:00 -0000 Message-ID: Subject: Re: [C++ Patch] PR 80955 (Macros expanded in definition of user-defined literals) To: Mukesh Kapoor Cc: Nathan Sidwell , gcc-patches List Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2017-10/txt/msg01700.txt.bz2 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. Jason