From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32585 invoked by alias); 14 Aug 2008 14:41:59 -0000 Received: (qmail 32563 invoked by uid 22791); 14 Aug 2008 14:41:57 -0000 X-Spam-Check-By: sourceware.org Received: from py-out-1112.google.com (HELO py-out-1112.google.com) (64.233.166.178) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 14 Aug 2008 14:41:19 +0000 Received: by py-out-1112.google.com with SMTP id d37so466759pye.29 for ; Thu, 14 Aug 2008 07:41:17 -0700 (PDT) Received: by 10.140.204.7 with SMTP id b7mr716479rvg.149.1218724876777; Thu, 14 Aug 2008 07:41:16 -0700 (PDT) Received: by 10.141.108.14 with HTTP; Thu, 14 Aug 2008 07:41:16 -0700 (PDT) Message-ID: <6c33472e0808140741hb83b278jad9b1a5b15e8ab02@mail.gmail.com> Date: Thu, 14 Aug 2008 15:03:00 -0000 From: "=?ISO-8859-1?Q?Manuel_L=F3pez-Ib=E1=F1ez?=" To: "Joseph S. Myers" Subject: Re: [PATCH] caret diagnostics (was: broken FE diagnostics wrt complex expressions) Cc: "Tom Tromey" , "Aldy Hernandez" , dberlin@dberlin.org, jakub@redhat.com, gcc@gcc.gnu.org, gdr@integrable-solutions.net, "Chris Lattner" , "Gcc Patch List" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6c33472e0808140340o2a56b9f4n149025bfa8426331@mail.gmail.com> <6c33472e0808140527i158255d9hdbc677bd0870cbc1@mail.gmail.com> <6c33472e0808140556y1f8975boaf41babaeec39f98@mail.gmail.com> X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2008-08/txt/msg00966.txt.bz2 2008/8/14 Joseph S. Myers : > > But in any case the default should be the default with no configure > option, users liking it should find their makefiles work the same > everywhere and users not liking it can add the opposite option. Then we are not going to get correct locations ever. New users do not read the manual. Neither old users do. New functionality disabled by default will be lost for both. I am fairly sure that a significant percentage of GCC developers (not just users) do not know about -fdiagnostics-show-option. But even more importantly. No GCC developer is going to explicitly enable caret diagnostics while developing GCC. How many nowadays use -fshow-column or -fdiagnostics-show-option to check locations? Moreover, caret diagnostics was mentioned as the way to solve the PRs that Aldy mentioned. If it is disabled by default, how does it solve anything? Why bother? I would really feel that I contributed to make GCC worse if GCC diagnostics are less expressive because we have the excuse of "you could enable the caret". I feel that a lot of PRs that request for better diagnostics would be closed that way. I feel that this thread is going again the same way as the ones before. Someone says: Hey, having caret diagnostics would solve a lot of problems! Everybody says: Yeah, that would be cool! We could do this and that and all kinds of cool things. Then someone says: Oh yes but we need to solve all these boring things that nobody ever really looks and it should be disabled by default. Then one year later someone says: Hey, having caret diagnostics would solve a lot of problems! Cheers, Manuel.