From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 44875 invoked by alias); 30 Nov 2016 17:08:22 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 44861 invoked by uid 89); 30 Nov 2016 17:08:21 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.8 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=eclipse, intuitive, hpp, FORCE_LANG_FLAG X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 30 Nov 2016 17:08:20 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id AE2E68F507; Wed, 30 Nov 2016 17:08:19 +0000 (UTC) Received: from [127.0.0.1] (ovpn03.gateway.prod.ext.phx2.redhat.com [10.5.9.3]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uAUH8H8G010008; Wed, 30 Nov 2016 12:08:18 -0500 Subject: Re: [PATCH 1/3] Fix mismatched struct vs class tags. To: Simon Marchi , John Baldwin References: <20161123200652.89209-1-jhb@FreeBSD.org> <1573845.CKxfuZpZBq@ralph.baldwin.cx> <31fa3dbd-e1d1-1fd2-7774-8bc82fd8b37d@redhat.com> <1853167.ixQKmG4D0P@ralph.baldwin.cx> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: <0cdddefe-faf8-9431-9fda-06f5bfff74ca@redhat.com> Date: Wed, 30 Nov 2016 17:08:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-11/txt/msg01004.txt.bz2 On 11/30/2016 04:50 PM, Simon Marchi wrote: > On 2016-11-30 11:23, John Baldwin wrote: >> One other clangism is that clang warns about compiling a .c file in C++. >> It wants an explicit '-x c++' to force the language mode. However, >> simply >> adding this to CXX_FLAGS doesn't work as it is included in both compiling >> and linking (and for the link it causes clang to try to parse all the >> object >> files as C++ source leading to bizarre errors). > > I think you could add it in its own variable: > > FORCE_LANG_FLAG = -x c++ > > and add that to INTERNAL_CFLAGS. > Sounds like it'd work. At least for gcc and clang. >> I assume a massive .c -> .cc >> (or .cxx, etc.) rename is not in the roadmap (it would presumably be very >> disruptive to pending patchsets)? > > I think it will have to be done at some point... it will be a bit weird > and counter intuitive for newcomers to see .c files containing C++. > That, and analysis tools that select the language based on the > extension. For example, I use Eclipse CDT for my development, and it > assumes C code for .c files by default. I can go change some obscure > setting to force it to consider it as C++, but it would be nicer for > everybody if we didn't have to do that. Actually, I just checked and > it's the same with vim and emacs. If we want to do it right, we would > have to rename .h into .hpp or .hh as well. And it would be as painful > to do it in 5 years as it would be to do it now, so I don't see why we > would wait... ".hh" and ".hpp" just look weird to me (for not being used to it, no doubt). But how are these tools handling the massive number of projects that use ".h" for C++ code? ( For emacs, we could put something in gdb/gdb-code-style.el / gdb/.dir-locals.el ) Thanks, Pedro Alves