From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) by sourceware.org (Postfix) with ESMTPS id 3E9733857828 for ; Fri, 7 Jan 2022 15:45:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3E9733857828 Received: by mail-pj1-x1034.google.com with SMTP id n30-20020a17090a5aa100b001b2b6509685so6767785pji.3 for ; Fri, 07 Jan 2022 07:45:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:from:to:references:in-reply-to :content-transfer-encoding; bh=fLVPAgE/G5A6WkcvirzQuWnwrxOaJjldEYHPyPAl8lU=; b=nTIrMncjdDdfEgZ2/IIbOSOsNFfIhsJFgpgWyxpAxRXLx0+2vd/9uzlxPcJxupNY+W Yv+kck9/9jQgKnOonIAJWNEw4DjI2gw1LksUIOH7SWIy1/5nSUj2Ojl7k/W4KlRDdQCY zDgdt6xrDnFH4LpDDGWQDcB4ULWtnsUdt0e/NbliArhTx2DiGmutPc26U0lOuoduXJyq 7ZKkj+yJ7xMwN8hEnLaNvi0CoCFD0kX7qqA2KfU929mcnpkmdFU5eHqMXzuEJbRSZgOm Xko4GKEvIUbY1eFOzZxH6dmAxCdbjVA4ARi9OFyB88WuqExMBaEidXtJsxhm13vOwerE YHnA== X-Gm-Message-State: AOAM532xZfxzONxa4EuVAD5OJUFQAuPh58XQiH7vbJjv2G6vF7c0YJ5k zyekOvEhCY3z5Pq6CIxOzwE= X-Google-Smtp-Source: ABdhPJzbNTKtcXfRSBhqalKBJqWcKaXTh2TQ+4JJl13ZgvsKlWBgaQgccCO/c3i1Om3jr7eCK8bkfw== X-Received: by 2002:a17:90a:9b88:: with SMTP id g8mr10301981pjp.178.1641570324244; Fri, 07 Jan 2022 07:45:24 -0800 (PST) Received: from [172.31.0.175] (c-98-202-48-222.hsd1.ut.comcast.net. [98.202.48.222]) by smtp.gmail.com with ESMTPSA id c17sm6456559pfc.163.2022.01.07.07.45.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 07 Jan 2022 07:45:23 -0800 (PST) Message-ID: Date: Fri, 7 Jan 2022 08:45:23 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Subject: Re: Mass rename of C++ .c files to .cc suffix? Content-Language: en-US From: Jeff Law To: Martin Jambor , GCC Mailing List References: <498a519b-a0d7-4281-6804-0f87469a670e@gmail.com> In-Reply-To: <498a519b-a0d7-4281-6804-0f87469a670e@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2022 15:45:26 -0000 On 1/7/2022 7:49 AM, Jeff Law wrote: > > > On 1/7/2022 3:25 AM, Martin Jambor wrote: >> Hi, >> >> Would anyone be terribly against mass renaming all *.c files (that are >> actually C++ files) within the gcc subdirectory to ones with .cc suffix? >> >> We already have 47 files with suffix .cc directly in the gcc >> subdirectory and 160 if we also count those in (non-testsuite) >> subdirectories, while the majority of our non-header C++ files still has >> the .c suffix. >> >> I have already missed stuff when grepping because I did not include *.cc >> files and the inconsistency is also just ugly and must be very confusing >> to anyone who encounters it for the first time. >> >> Since we have switched to git, this should have quite small effect on >> anyone who does their development on branches.  With Martin Liška we did >> a few experiments and git blame, git rebase and even git gcc-backport >> worked seamlessly across a rename. >> >> I would be fine waiting with it until GCC 12 gets released but see >> little value in doing so. >> >> What do others think?  (Any important caveats I might have missed?) > I think it's well past time we do this.   There may be a bit of pain > with cherry-picking across the rename point, but we should just deal > with it.  I realized this might be mis-interpreted.  The "well past time" was really meant to signal that I think we probably should have made this change long ago and that waiting even longer just doesn't make sense to me. I'm fully in favor and have no objections to making it now.  I wouldn't be terribly surprised if it's less intrusive to make now rather than after gcc-12 is released.  Making it now affects trunk->gcc11 and earlier backports which should be smaller than trunk->gcc-12 backports we'd be making in the summer/fall if we were to defer until after gcc-12. jeff