From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8895 invoked by alias); 13 Apr 2012 01:03:49 -0000 Received: (qmail 8879 invoked by uid 22791); 13 Apr 2012 01:03:47 -0000 X-SWARE-Spam-Status: No, hits=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,KHOP_THREADED X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 13 Apr 2012 01:03:34 +0000 From: "manu at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/52957] Missing suggestions on '=' and '==' confusion Date: Fri, 13 Apr 2012 01:03:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: manu at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2012-04/txt/msg00960.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D52957 --- Comment #5 from Manuel L=C3=B3pez-Ib=C3=A1=C3=B1ez 2012-04-13 01:03:28 UTC --- Maintainers (those who decide) are too few and they either do not care or do not have time to fix these things. Existing or new contributors that are pa= id to do something specific don't care about anything else as long as it doesn= 't interfere with their job (if it does, whatever improvement it may be, then = they are against it). I don't think there is any GCC contributor that is paid to improve GCC's diagnostics (am I wrong?). This is very different from Clang, where Chris obviously cares a great deal about Clang's diagnostics, and it seems to be supported by a team in Apple (and in Google?). Contributors to GCC that care about these things, either unpaid or in their free time, are very few and completely overworked. It is true that the GCC = code base has a huge technical debt, but diagnostic fixes tend to be easy to fix= , if you have a little of experience. However, there are a lot of them, and gett= ing patches reviewed and accepted requires herculean amounts of perseverance. B= ut probably you can share with me more about your (or Googlers) thoughts on the latter, since you have the experience of submitting the same project to both LLVM and GCC. New contributors to GCC are almost non-existent (except those that are paid= to work on very specific stuff, like a new port, but these new contributors al= so don't care about GCC in general, as long as it doesn't interfere with their job). The reasons why GCC fails to attract new contributors are very well-known: the copyright assignment is a major hurdle for casual/unpaid contributors, patches from new contributors are routinely ignored and the p= atch review process is hostile to new contributors (in reality, much less than in the Linux kernel, but they have enough developers to afford being hostile). Interacting for the first time with GCC developers can easily discourage a = lot of people (there is a whole page just on the subject! http://gcc.gnu.org/wiki/GCC_Research). In Clang for example, small obvious fixes proposed by new contributors without any changelog or even without a patch are often committed immediately. I have never seen this in +6 years contributing to GCC, on the contrary, the contributor will be asked to bootstrap, regtest, provide a Changelog, fix the Changelog, provide a patch, read the code style, fix the code style, some bikeshedding, and between each step, there may be weeks of no feedback at all. GCC also has a huge marketing problem, no overall vision, no clear leadersh= ip (it is easy to get contradictory answers by the people who decide), and GCC developers show both a lack of enthusiasm (just compare presentations by Clang/LLVM developers, full of amazing features, awesome graphics, never-seen-before numbers and LLVM webpages are full of how good their comp= iler is, how much better than anything else, etc.) and a sense of superiority ("= we don't want to be like Clang/LLVM! It produces slower code by 0.0001%! It doesn't support mmix-knuth-mmixware"). These kind of things are essential to attract new contributors, however, they do not seem to provide any advantag= e to existing developers, and they are seen as pointless extra work better done = by, wait for it, new contributors. Nothing of the above gets fixed by switching to C++ or by having a clearly defined AST...