From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id CB4E33986828 for ; Wed, 16 Jun 2021 16:35:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CB4E33986828 Received: from mail-qv1-f69.google.com (mail-qv1-f69.google.com [209.85.219.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-281-z3LXb2GfOeGHBxdhZ6j8IA-1; Wed, 16 Jun 2021 12:35:40 -0400 X-MC-Unique: z3LXb2GfOeGHBxdhZ6j8IA-1 Received: by mail-qv1-f69.google.com with SMTP id r8-20020a0562140c88b0290242bf8596feso8306qvr.8 for ; Wed, 16 Jun 2021 09:35:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=dkKYHkhybeIrKAjKa2LO7szh4AhWcPMunDgJCaoH1Bs=; b=a0O6PRW6WTbVvcc/by6FBiJ7XCg2InIdNcvx/G7cVeqinVyZY5Zbr+aCULX3KvSWZ+ 56NNnntth1+nCA1LsGmk4KwxtHta177C4ShgWc5RvS+bxJBrWn8FFb1k1wscuLSQn9n+ PYmlH4ELBfDjPMfwNp0dg89Cwj3DkGW6e4PqUrNJR4ZkBbPg3UHFFn3S+EJwuuLwXQrH ceowpKIYNqjicHULe4wyNyxpByIFY/SPvw5NWY9thz9CR3NjYF7Mc6XO1EKejgZeBnD3 uz8hQTA8M4og0zG5+985zG8TsqXq1SyvGAJ+8ROllQIQ+vtVSiewcaoQB1ev+nWHgKjy JKRQ== X-Gm-Message-State: AOAM530MVQYNNrsmXjNK/AFgPa7S+tvHIhbsO2w5edCzkATIBpR6HCwy 4RPYeuZfGh7i61vEWxTZOZf5hyhqSY73ljny4mDec9rJ//f1yW45nwYXRCz7f63MR0uGFTN9/Ji fnpD3OBg3tJ4ic/Dj3lmYfZRUVN019J4zUIztsOpqP22z+qxzT4NPeuTBFNi0hIyonQ== X-Received: by 2002:a37:c13:: with SMTP id 19mr935981qkm.354.1623861339023; Wed, 16 Jun 2021 09:35:39 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzE+Orm4HVY9lkcQ7vAmgyRqc6uXEonFCQ1o51It2LsK9hPANLwpNFQz3k43nf0Uvrhd5uHDQ== X-Received: by 2002:a37:c13:: with SMTP id 19mr935956qkm.354.1623861338700; Wed, 16 Jun 2021 09:35:38 -0700 (PDT) Received: from [192.168.1.148] (130-44-159-43.s11817.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [130.44.159.43]) by smtp.gmail.com with ESMTPSA id u3sm1584887qtg.16.2021.06.16.09.35.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 16 Jun 2021 09:35:38 -0700 (PDT) Subject: Re: [PATCH] make rich_location safe to copy To: Martin Sebor , David Malcolm , gcc-patches References: <88448f63-87ad-c3a5-d38b-c94dd825e8d2@gmail.com> <0b9651cb91da83738060095f6adecd7f02392e55.camel@redhat.com> <0eb421c1-4a84-e776-8be7-9887aab36e81@gmail.com> <558c61be-f93f-75e9-3a14-d2d7d79bc751@gmail.com> From: Jason Merrill Message-ID: <7e656451-95e4-5ebd-4988-1eb2d539983f@redhat.com> Date: Wed, 16 Jun 2021 12:35:37 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <558c61be-f93f-75e9-3a14-d2d7d79bc751@gmail.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.2 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2021 16:35:44 -0000 On 6/16/21 12:11 PM, Martin Sebor wrote: > On 6/16/21 9:06 AM, David Malcolm wrote: >> On Wed, 2021-06-16 at 08:52 -0600, Martin Sebor wrote: >>> On 6/16/21 6:38 AM, David Malcolm wrote: >>>> On Tue, 2021-06-15 at 19:48 -0600, Martin Sebor wrote: >>>> >>>> Thanks for writing the patch. >>>> >>>>> While debugging locations I noticed the semi_embedded_vec template >>>>> in line-map.h doesn't declare a copy ctor or copy assignment, but >>>>> is being copied in a couple of places in the C++ parser (via >>>>> gcc_rich_location).  It gets away with it most likely because it >>>>> never grows beyond the embedded buffer. >>>> >>>> Where are these places?  I wasn't aware of this. >>> >>> They're in the attached file along with the diff to reproduce >>> the errors. >> >> Thanks. >> >> Looks like: >> >>     gcc_rich_location richloc = tok->location; >> >> is implicitly constructing a gcc_rich_location, then copying it to >> richloc.  This should instead be simply: >> >>     gcc_rich_location richloc (tok->location); >> >> which directly constructs the richloc in place, as I understand it. > > I see, tok->location is location_t here, and the gcc_rich_location > ctor that takes it is not declared explicit (that would prevent > the implicit conversion). > > The attached patch solves the rich_location problem by a) making > the ctor explicit, b) disabling the rich_location copy ctor, c) > changing the parser to use direct initialization.  (I CC Jason > as a heads up on the C++ FE bits.) The C++ bits are fine. > The semi_embedded_vec should be fixed as well, regardless of this > particular use and patch.  Let me know if it's okay to commit (I'm > not open to disabling its copy ctor). > + /* Not copyable or assignable. */ This comment needs a rationale. Jason