[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: scratch/accurate-warning-pos: Solid progress: the branch now bootstr

From: Paul Eggert
Subject: Re: scratch/accurate-warning-pos: Solid progress: the branch now bootstraps.
Date: Tue, 27 Nov 2018 17:11:48 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1

On 11/27/18 1:53 PM, Alan Mackenzie wrote:
Macros would mess things up. For example, after expanding a macro like the contrived
    (defmacro dehash (form)
      (copy-tree form))

, how would the recorded cons locations be linked up with the resulting

People typically don't write macros like that, so we needn't tune our design for it. More commonly, people write macros containing errors, such as:

  (defmacro face-attribute-specified-or (value default &rest body)
    (let ((temp (make-symbol "value")))
         (let ((,temp ,value))
           (if (eq ,temp 'unspecified)
               (progn ,@body)

This has a parenthesization typo and the macro doesn't mean what the user probably intended. For these macros, as I understand it the symbols-with-pos approach messes up because the symbol associated with the error was built by make-symbol and doesn't have a source code position. In contrast, the cons-with-pos approach should return a good location in the macro itself for the undeclared symbol (i.e., just before the last ",temp").

One can also come up with examples where the symbols-with-pos approach is better than the cons-with-pos approach. That is, neither approach dominates the other. So, which approach would be better in practice? I don't think we know.

the "slow" Emacs would somehow need to be used by the byte compiler after Emacs has been built, to continue to get accurate warning locations.

That's easy enough: the fast Emacs can fork and exec the slow one, which can be installed next to movemail etc. (Again, not that I like this approach.)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]