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 [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id C2DBB3850416 for ; Wed, 16 Jun 2021 12:38:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C2DBB3850416 Received: from mail-qt1-f200.google.com (mail-qt1-f200.google.com [209.85.160.200]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-208-_gV479OcMRKyH7yl7CSh-g-1; Wed, 16 Jun 2021 08:38:32 -0400 X-MC-Unique: _gV479OcMRKyH7yl7CSh-g-1 Received: by mail-qt1-f200.google.com with SMTP id r17-20020ac842510000b02902456ec03025so1496241qtm.3 for ; Wed, 16 Jun 2021 05:38:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=sFBo4LtjtUBwwP6iPpL0aH0IBmxeUZrFy+rM2NLiMyM=; b=Id9kiICJxNoXThq8MzhYZw3ECyJIxnBeU7QVCBqiDh7hFfhLRLVBHnnmu6zre1iECp 1ToHA7ueDdS8JSw7Y9F+TN4HrLeHn/K1p8vKLTfJe8RWyLc7jAOk/QPnb5DmIVs2ihYh KjUi56ZyCOlXHUFMEy5Frogd1f4+qToZ52iXGGR9HOIDGRM1cto0Xm6hYyuNuLY4Y5Na kZbx3caChQcvKRipeL77sD6egbRE3Lat6pxdmpQSBq3HLj7soKlU7H/jLlyc0jT+Wo8J E95cuYnZVUgaGMVEIJ7JGwg664tkgfY1xn94y5kqI+hZHyr5TwliIKLCA+huf8ZzXGaZ LJoA== X-Gm-Message-State: AOAM5326gJQttEqFtVybboMwXMzbaiGR4pB8cldIq4bcqGfJFSgwf2kG dieLxKlfPTbY/S/HuKn73NiYnrtDzs6zlMe4tOmw+RaYMgn/hbGLe3kDb7S/5CdYXWBn4EZli5D lCu9dC0+khmittuOEvA== X-Received: by 2002:a05:620a:290b:: with SMTP id m11mr4943736qkp.455.1623847112153; Wed, 16 Jun 2021 05:38:32 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzsrGejjA0BJRWhEimDuKukhKsZi1xA6eWk2i5g3cT1OoNbv1+tizrQptYRInWTu5EByrlaOw== X-Received: by 2002:a05:620a:290b:: with SMTP id m11mr4943716qkp.455.1623847111937; Wed, 16 Jun 2021 05:38:31 -0700 (PDT) Received: from t14s.localdomain (c-73-69-212-193.hsd1.ma.comcast.net. [73.69.212.193]) by smtp.gmail.com with ESMTPSA id o123sm1484260qkd.6.2021.06.16.05.38.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Jun 2021 05:38:30 -0700 (PDT) Message-ID: <0b9651cb91da83738060095f6adecd7f02392e55.camel@redhat.com> Subject: Re: [PATCH] make rich_location safe to copy From: David Malcolm To: Martin Sebor , gcc-patches Date: Wed, 16 Jun 2021 08:38:29 -0400 In-Reply-To: <88448f63-87ad-c3a5-d38b-c94dd825e8d2@gmail.com> References: <88448f63-87ad-c3a5-d38b-c94dd825e8d2@gmail.com> User-Agent: Evolution 3.38.4 (3.38.4-1.fc33) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.9 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, 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 12:38:36 -0000 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. > > The attached patch defines the copy ctor and also copy assignment > and adds the corresponding move functions. Note that rich_location::m_fixit_hints "owns" the fixit_hint instances, manually deleting them in rich_location's dtor, so simply doing a shallow copy of it would be wrong. Also, a rich_location stores other pointers (to range_labels and diagnostic_path), which are borrowed pointers, where their lifetime is assumed to outlive any (non-dtor) calls to the rich_location. So I'm nervous about code that copies rich_location instances. I think I'd prefer to forbid copying them; what's the use-case for copying them? Am I missing something here? > > Tested on x86_64-linux. > > Martin Thanks Dave