From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 35773 invoked by alias); 1 Dec 2015 17:35:01 -0000 Mailing-List: contact fortran-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: fortran-owner@gcc.gnu.org Received: (qmail 34783 invoked by uid 89); 1 Dec 2015 17:35:00 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_20,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-ig0-f180.google.com Received: from mail-ig0-f180.google.com (HELO mail-ig0-f180.google.com) (209.85.213.180) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 01 Dec 2015 17:34:59 +0000 Received: by igcto18 with SMTP id to18so11985751igc.0; Tue, 01 Dec 2015 09:34:57 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.56.114 with SMTP id z18mr27617768igp.62.1448991297749; Tue, 01 Dec 2015 09:34:57 -0800 (PST) Received: by 10.36.200.70 with HTTP; Tue, 1 Dec 2015 09:34:57 -0800 (PST) In-Reply-To: <20151201164139.GA21769@troutmask.apl.washington.edu> References: <1448974501-30981-1-git-send-email-rep.dot.nop@gmail.com> <1448974501-30981-4-git-send-email-rep.dot.nop@gmail.com> <20151201150153.GA20747@troutmask.apl.washington.edu> <20151201164139.GA21769@troutmask.apl.washington.edu> Date: Tue, 01 Dec 2015 17:35:00 -0000 Message-ID: Subject: Re: [PATCH] RFC: Use Levenshtein spelling suggestions in Fortran FE From: Bernhard Reutner-Fischer To: Steve Kargl Cc: gfortran , GCC Patches , David Malcolm Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-12/txt/msg00013.txt.bz2 On 1 December 2015 at 17:41, Steve Kargl wrote: > On Tue, Dec 01, 2015 at 05:12:57PM +0100, Bernhard Reutner-Fischer wrote: >> On 1 December 2015 at 16:01, Steve Kargl >> wrote: >> > On Tue, Dec 01, 2015 at 01:55:01PM +0100, Bernhard Reutner-Fischer wrote: >> >> >> >> David Malcolm nice Levenshtein distance spelling check helpers >> >> were used in some parts of other frontends. This proposed patch adds >> >> some spelling corrections to the fortran frontend. >> >> > What problem are you trying to solve here? The patch looks like >> >> The idea is to improve the programmer experience when writing code. >> See the testcases enclosed in the patch. I consider this a feature :) > > Opinions differ. I consider it unnecessary bloat. Fair enough. I fully agree that it's bloat. The compiler is so tremendously bloated by now anyway that i consider these couple of kilobyte to have a nice bloat/user friendliness factor, overall ;) I can imagine that people code their fortran programs in an IDE (the bloated variant of an editor, mine is ~20518 bytes of text, no data, no bss) and IDEs will sooner or later support fixit-hints. Even the console/terminal users might enjoy to safe them a cycle of opening a different file, looking up the type/module/etc name and then going back to the source-file to correct their typo. *I* would welcome that sometimes for sure :) >> > unneeded complexity with the result of injecting C++ idioms into >> > the Fortran FE. >> >> What C++ idioms are you referring to? The autovec? >> AFAIU the light use of C++ in GCC is deemed OK. I see usage of >> std::swap and std::map in the FE, not to mention the wide-int uses >> (wi::). Thus we don't have to realloc/strcat but can use vectors to >> the same effect, just as other frontends, including the C frontend, >> do. >> I take it you remember that we had to change all "try" to something >> C++ friendly. If the Fortran FE meant to opt-out of being compiled >> with a C++ compiler in the first place, why were all the C++ clashes >> rewritten, back then? :) > > Yes, I know there are other C++ (mis)features within the > Fortran FE especially in the trans-*.c files. Those are > accepted (by some) as necessary evils to interface with > the ME. Your patch injects C++ into otherwise perfectly > fine C code, which makes it more difficult for those with > no or very limited C++ knowledge to maintain the gfortran. So you're in favour of using realloc and strcat, ok. I can use that. Let me see if ipa-icf can replace all the identical tails of the lookup_*_fuzzy into a common helper. Shouldn't rely on LTO anyway nor ipa-icf i suppose. > > There are currently 806 open bug reports for gfortran. > AFAIK, your patch does not address any of those bug reports. I admit i didn't look.. > The continued push to inject C++ into the Fortran FE will > have the (un)intentional consequence of forcing at least one > active gfortran contributor to stop. That was not my intention for sure. cheers,