From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21849 invoked by alias); 3 Dec 2015 13:53:08 -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 21827 invoked by uid 89); 3 Dec 2015 13:53:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: smtp26.services.sfr.fr Received: from smtp26.services.sfr.fr (HELO smtp26.services.sfr.fr) (93.17.128.163) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 03 Dec 2015 13:53:06 +0000 Received: from filter.sfr.fr (localhost [86.72.15.34]) by msfrf2603.sfr.fr (SMTP Server) with ESMTP id 4A2D41C024864; Thu, 3 Dec 2015 14:53:03 +0100 (CET) Authentication-Results: sfrmc.priv.atos.fr; dkim=none (no signature); dkim-adsp=none (no policy) header.from=mikael.morin@sfr.fr Received: from [192.168.1.85] (34.15.72.86.rev.sfr.net [86.72.15.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by msfrf2603.sfr.fr (SMTP Server) with ESMTP id B4EB71C02484F; Thu, 3 Dec 2015 14:53:02 +0100 (CET) X-SFR-UUID: 20151203135302741.B4EB71C02484F@msfrf2603.sfr.fr Subject: Re: [PATCH] RFC: Use Levenshtein spelling suggestions in Fortran FE To: Janne Blomqvist , Bernhard Reutner-Fischer References: <1448974501-30981-1-git-send-email-rep.dot.nop@gmail.com> <1448974501-30981-4-git-send-email-rep.dot.nop@gmail.com> <1448990880.8490.24.camel@surprise> Cc: David Malcolm , gfortran , GCC Patches From: Mikael Morin Message-ID: <56604942.6060807@sfr.fr> Date: Thu, 03 Dec 2015 13:53:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2015-12/txt/msg00036.txt.bz2 Le 03/12/2015 10:29, Janne Blomqvist a écrit : > On Tue, Dec 1, 2015 at 7:51 PM, Bernhard Reutner-Fischer > wrote: >> As said, we could as well use a list of candidates with NULL as record marker. >> Implementation cosmetics. Steve seems to not be thrilled by the >> overall idea in the first place, so unless there is clear support by >> somebody else i won't pursue this any further, it's not that i'm bored >> or ran out of stuff i should do.. ;) > > FWIW, I think the idea of this patch is quite nice, and I'd like to > see it in the compiler. > I like this feature as well. > I'm personally Ok with "C++-isms", but nowadays my contributions are > so minor that my opinion shouldn't carry that much weight on this > matter. > Same here. David Malcolm suggested to move the candidate selection code to the common middle-end infrastructure, which would move half of the so-called "bloat" there. Steve, would that work for you? It seems to me that the remaining C++-isms are rather acceptable. I do agree that the vec implementation details seem overly complex for something whose job is just the memory management of a growing (or shrinking) vector. However, the API is consistent and self-explanatory, and the usage of it that is made here (just a few "safe_push") is not more complex than what would be done with a C-only API. Mikael