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

[Paul Eggert]

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
> form?

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")))
      `(or
         (let ((,temp ,value))
           (if (eq ,temp 'unspecified)
               (progn ,@body)
             default))
         ,temp)))

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