Re: Correct byte compiler error/warning positions. The solution!

[Andrea Corallo]

Alan Mackenzie <acm@muc.de> writes:

> Hello, Andrea.

Hi Alan,

> On Wed, Dec 01, 2021 at 17:53:03 +0000, Andrea Corallo wrote:
>> Eli Zaretskii <eliz@gnu.org> writes:
>
>> [...]
>
>> > If all the benchmarks show a slowdown <= 1%, I'm okay with merging it.
>
>> > Thanks.
>
>> Another quick note, I think we should evaluate the impact not only with
>> different benchmarks but also using a native compiled build (ATM the
>> branch has no support for that).
>
> The change to the scratch/correct-warning-pos branch to work with native
> compilation is probably quite small,

Not so sure about that

> but I don't know the native code
> compiler (comp.el, etc.) at all.
>
> Would you help me with it, please.

Sure

> The mechanism of the change was introducing @dfn{symbols with position}.
> These are embodied in src/lisp.h with a new type tag
> PVEC_SYMBOL_WITH_POS, and the type struct Lisp_Symbol_With_Pos.
>
> The most pertinent changes in the branch are likewise those in
> src/lisp.h.  There, there's a new flag variable,
> symbols_with_pos_enabled, which is tested in the macros lisp_h_EQ,
> lisp_h_SYMBOLP, and in the inline function XSYMBOL.  There are new
> "primitive" macros, lisp_h_BASE_EQ, lisp_h_BARE_SYMBOL_P, and the inline
> function XBARE_SYMBOL.  There are a few other things too, like
> lisp_h_SYMBOL_WITH_POS_P.
>
> All these changes can be seen with a git diff between the branch head
> and the branch point in the master branch.

The modifications needed are all and only going into comp.c.

The function you have to extend is 'emit_EQ'.  You'll see we have an
emit_* function for each corresponding macro/inline function used, ex:
'emit_XLI', 'emit_XCONS' etc...

You'll have to define all the new one needed in order to use them use
them in the new 'emit_EQ'.

Best Regards

  Andrea