Re: Changing a cl-defstruct definition in a published package

["Clément Pit-Claudel" <cpitclaudel@gmail.com>]

On 2018-07-13 16:40, Stefan Monnier wrote:
>>> I don't know what you're trying to do, but the only way is not to change
>>> the object layout, and to guarantee that the value that the user
>>> packages are looking for is indeed found there at the right time.  A
>>> potentially horrible amount of hookage awaits you, but you could at
>>> least also add your new feature/change and get rid of the hacks later.
>>
>> :(. I'm going to wait for a bit and hope that someone thinks of
>> a clever workaround :) Is there a way to tell package.el to recompile
>> another package, maybe?
> 
> I don't think I could come up with a clever workaround without knowing
> the details (because the clever workaround will almost invariably
> take advantage of some aspect of those details).

I'm happy to provide more details, then.  The currently problematic implementation is at https://github.com/flycheck/flycheck/pull/1400

Flycheck currently stores its error list as a list of error structs:

(cl-defstruct (flycheck-error
               (:constructor flycheck-error-new)
               (:constructor flycheck-error-new-at
                             (line column
                                   &optional level message
                                   &key checker id group
                                   (filename (buffer-file-name))
                                   (buffer (current-buffer)))))
  buffer checker filename line column message level id group)

We're hoping to change it to this:

  …
  buffer checker filename -coordinates -region message level id group)

`-coordinates' is another struct with 4 fields (line-start, column-start, line-end, and column-end). `-region' is a cons cell of two buffer positions.  The idea is that checker can supply either line/column coordinates or directly a region.

These two are prefixed with `-' because they are wrapped by accessors, to support either representation and lazily convert between them: if code needs a region it uses the wrapper for -region, which ensures that that field is populated, and conversely when code (e.g. the error list) needs a line number, it gets it through a wrapper that guarantees that the number has been computed.

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).

Let me know if there's any extra info I can provide.

Cheers,
Clément.