On 1 December 2015 at 17:41, Steve Kargl <s...@troutmask.apl.washington.edu> wrote: > On Tue, Dec 01, 2015 at 05:12:57PM +0100, Bernhard Reutner-Fischer wrote: >> On 1 December 2015 at 16:01, Steve Kargl >> <s...@troutmask.apl.washington.edu> 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,
