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.129.124]) by sourceware.org (Postfix) with ESMTPS id 1F5193858412 for ; Fri, 7 Jan 2022 16:00:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1F5193858412 Received: from mail-qk1-f198.google.com (mail-qk1-f198.google.com [209.85.222.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-393-ycac_cIKPQOVS4couz3AUw-1; Fri, 07 Jan 2022 10:59:56 -0500 X-MC-Unique: ycac_cIKPQOVS4couz3AUw-1 Received: by mail-qk1-f198.google.com with SMTP id bq9-20020a05620a468900b004681cdb3483so4343996qkb.23 for ; Fri, 07 Jan 2022 07:59:56 -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:subject:from:to:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=B+qkQZoJIYKe+erGAEma58kAwIoflG/9//YI8UKtG7U=; b=NG/V41yZh3EnjlRmQdtc1mAxmZNON9HgxfJVllK/ruPfx7MNRC8AQ2cAGyIZrHbDTw aMModinksbAtyesxJH6DZAg7Snvl6+dWAVx4XZnPSZCqkvfCXJAIJrxAgBmRRHvueeoV GT6M6CVaJoUGdV8IK0SkRJ18NQmluEdnnr7QTIOeOLk3e0cWM8O2aFQJX57YmQsjzkD9 rm0lMYRyfmNxxw9fBYM8VhdDRUwvVrh4/ppx2toIzuFmJK3Ax15UjiQKFxP+APELKqIk p716zjdEPJB3lBw1b8+3hgYDW/B9c5MW9q6TKTO/rpC71qqNcwxvYCwcEYTHc6jgW2pj e9cQ== X-Gm-Message-State: AOAM532tQOdDusUOH3rvAiKALgVAeHKUGE9i8Se0PyloFTIcGYt0IUyZ aCvcxlt1yUK74U3b2C48iMYFz8KZRrwY543HHvW9z2U+m61JKi1fZLJmotayxtyenvZaow2g9fZ 6xTLyIhg= X-Received: by 2002:ac8:5c49:: with SMTP id j9mr57471887qtj.253.1641571196262; Fri, 07 Jan 2022 07:59:56 -0800 (PST) X-Google-Smtp-Source: ABdhPJzPkTHjPRiRkYARCRCAXqJKMvDxJJYQesD537Bwz8MU5pnK6BUpjDlybGNnZ6Bss36OT6oeig== X-Received: by 2002:ac8:5c49:: with SMTP id j9mr57471872qtj.253.1641571195992; Fri, 07 Jan 2022 07:59:55 -0800 (PST) Received: from t14s.localdomain (c-73-69-212-193.hsd1.nh.comcast.net. [73.69.212.193]) by smtp.gmail.com with ESMTPSA id t30sm3462260qkj.125.2022.01.07.07.59.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 07 Jan 2022 07:59:55 -0800 (PST) Message-ID: <34a5f90cd4a52b3a4a7fecb0ba7b082a02f0c6b7.camel@redhat.com> Subject: Re: Mass rename of C++ .c files to .cc suffix? From: David Malcolm To: Martin Jambor , GCC Mailing List Date: Fri, 07 Jan 2022 10:59:54 -0500 In-Reply-To: References: 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=-6.0 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_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, 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 16:00:16 -0000 On Fri, 2022-01-07 at 11:25 +0100, 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?) +1 from me. Various details: Presumably the generated files should also change from .c to .cc (e.g. gengtype generates a gtype-desc.c which is actually C++). grep for "files_rules" in gengtype: it seems to have some hardcoded regex patterns that end in "\\.c" (not sure what these do, but should be investigated w.r.t. a renaming to .cc) A minor detail that would be nice to get right: the selftests manually code the names of source files in function names; see selftest::run_tests in selftest-run-tests.c, which has lots of calls to functions of the form "foo_c_tests ();" These function names should probably be renamed to "foo_cc_tests" if "foo.c" is renamed to "foo.cc". Though perhaps that can wait to a followup, or be a separate commit, if that helps with backporting. Hope this is constructive Dave