From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: =?UTF-8?Q?Cl=c3=a9ment_Pit-Claudel?= Newsgroups: gmane.emacs.devel Subject: Re: Changing a cl-defstruct definition in a published package Date: Sun, 15 Jul 2018 00:25:02 -0400 Message-ID: <133dfba4-e6c7-3aca-a39f-4d26a688c8b5@gmail.com> References: <9afc36c6-5759-6ea0-4cd4-9d6eb6b073b5@gmail.com> <87601jx6xa.fsf@gmail.com> <8806cd3a-da5f-28da-1aa6-fff611214396@gmail.com> <33b59faf-9357-706e-2239-68411096bc51@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1531628627 8858 195.159.176.226 (15 Jul 2018 04:23:47 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 15 Jul 2018 04:23:47 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 15 06:23:43 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1feYZS-0002DZ-1J for ged-emacs-devel@m.gmane.org; Sun, 15 Jul 2018 06:23:42 +0200 Original-Received: from localhost ([::1]:44264 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1feYbX-0002VG-7w for ged-emacs-devel@m.gmane.org; Sun, 15 Jul 2018 00:25:51 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57721) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1feYao-0002VA-1y for emacs-devel@gnu.org; Sun, 15 Jul 2018 00:25:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1feYan-0007Ho-9w for emacs-devel@gnu.org; Sun, 15 Jul 2018 00:25:06 -0400 Original-Received: from mail-qk0-x22f.google.com ([2607:f8b0:400d:c09::22f]:35688) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1feYan-0007HO-5P for emacs-devel@gnu.org; Sun, 15 Jul 2018 00:25:05 -0400 Original-Received: by mail-qk0-x22f.google.com with SMTP id u21-v6so19101006qku.2 for ; Sat, 14 Jul 2018 21:25:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=HjNGWFnir2KziR8tk4oL7wuJ+O8MjTSuRyBMoTDEhZA=; b=ByxzwcdbL0XTug3hh4y5n/bzoLD30udGKHM7wyBzX4uULqfDCS+nXehZ87HlQuS/Ld V0xvBAyXX6FgdgaCEbCe27bt6d4cB8QyiPT/0Weld/fhUaFLcASwJ8YgY2Y094tvMVI5 oNkyjTovGcZRl7dPMVIJx7lkkc8/B0VlU8G9YoP+ERsARLHgJekEdTtqJIPkdEYVxO5g PL41TdJa9PE3bDiSgzYewpG09xu33IBbQMSODBVkpozaIhajWOzmbwLH+KZ5rbqdfkJw pYVY7MWRVxCmIWWyTmdSlLxPrvfZ9+vE69ECt0ZgdvshBx9ShSWaV788erBFSXHPoZdj /6+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=HjNGWFnir2KziR8tk4oL7wuJ+O8MjTSuRyBMoTDEhZA=; b=I+/kxnyuoNeSHVQQpVOHcrGQWyDeT6dBcF4DBLiITRxuhSsCFSGSe2rUXmw8HiAPWt PE/y+pmIRxr0rFrDTLmcdt22ZdpgskfWI+jYhJNHUe7qDkJ8M3JOEwLpx7XG9xUNSL1x EbHp7AgFO8qltqCI6wq35MMxMZ7AQA1Jo8dOPtlhwyeTsarR5oqZdSJ4a9BNAXQbUVjb xVNfTyQdChJY+h9cbyvoSBvkMigHDLbm2mpjYw9OxPH4uuEopyptQ7zocOHPVKhbBGfl +8I85f3DY0cKSc1oJQzlkfBRKUACHeCVMRz/RpuDl6Grcpxd3OCcsBKK5S327AvQzTBc iXOg== X-Gm-Message-State: AOUpUlEUxs50DNqluf1O9RA09t6VU4hDMwebfKRevmUuZkCMMpWXz++Y EuUYa9HdQeSQNp/dZqOHzgOYRme2 X-Google-Smtp-Source: AAOMgpfCO5+4X2CY556jD7RTl3PrsWbFJkw4hW8xe9ozIyxnVE9IBS063eP8IaCzZPVgulDnV++NKQ== X-Received: by 2002:a37:b102:: with SMTP id a2-v6mr10168308qkf.359.1531628704115; Sat, 14 Jul 2018 21:25:04 -0700 (PDT) Original-Received: from ?IPv6:2601:184:4180:66e7:8c91:a307:4721:dd91? ([2601:184:4180:66e7:8c91:a307:4721:dd91]) by smtp.gmail.com with ESMTPSA id c20-v6sm16899180qtq.30.2018.07.14.21.25.02 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 14 Jul 2018 21:25:03 -0700 (PDT) In-Reply-To: Content-Language: en-GB X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:400d:c09::22f X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:227420 Archived-At: On 2018-07-13 23:36, Stefan Monnier wrote: >> buffer checker filename line column message level id group) > [...] >> buffer checker filename -coordinates -region message level id group) > > OK, so the issue is with `line` and `column` which get replaced by > `-coordinates` and `-region`, the rest stays unchanged. So maybe you > can arrange to auto-detect objects created with the old format. Thanks Stefan, your help and advice are much appreciated. >> Most Flycheck checkers are defined using a standardized macro and do >> not have to worry about creating or accessing individual error >> structures, so that code is fine. More complex error checkers, on the >> other hand, do create error objects directly (concrete examples >> include merlin, or any of the checkers that maintain a persistent >> background process). > > IIUC, outside Flycheck the main operation called (and hence inlined) is > the constructor(s). Are field accessors also used outside Flycheck? > If so, is there a chance that they are only ever used on those objects > that were created by the outside code as well (i.e. those inlined > accessors only see objects created by the compatible inline > constructors)? I don't think so. We have multiple types of extensions, including error checkers (which create new objects and use accessors on them, then pass them to Flycheck core which also accesses fields on them) and UI plugins that take errors produced by the core or plugins and access their fields. > I get the impression that maybe you can write a wrapper to access > `-coordinates` and `-region` which will check if either of those is of > the wrong type (but of the right type for `line` and `column` instead) > so it will know to fallback on the new code? This might be possible. I will investigate and possibly follow up. I wonder if there may be a trick to force recompilation of dependencies. Maybe this is something package.el should support ? A field like Must-recompile-version: 0.1 would mean that when upgrading from anything before 0.1 to 0.1 or later package.el should recompile all dependencies, too. Is there a setting to tell cl-defstruct to not generate macros for constructors and accessors? Clément.