Re: native-comp-async-report-warnings-errors default value

[Andrea Corallo <akrl@sdf.org>]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 25.12.2021 13:53, Andrea Corallo wrote:
>> Dmitry Gutov <dgutov@yandex.ru> writes:
>> 
>>> Hi Andrea,
>>>
>>> On 24.12.2021 12:53, Andrea Corallo wrote:
>>>> this is not a trivial modification so I might easily miss some aspects
>>>> of it but...
>>>> Certanly bytecode ATM has no way to store declaration specifiers and
>>>> these are used for native compilation.  I guess we should at least
>>>> extend this first.
>>>
>>> Thanks for the answer, I really wanted at least a high-level
>>> understanding of this point. I wouldn't presume to ask you to work on
>>> this, but maybe some of the others here who also complained about the
>>> warnings, would be interested in taking the initiative?
>>>
>>> Regarding declaration specifiers, I think the new (declare (modes
>>> ...)) feature had the same problem.
>>>
>>> Not sure how it was solved (or whether it was solved at all).
>> I guess the mode declaration has affect during byte compilation so
>> it
>> should be fine.  The issue is for other declarations that are taking
>> effect afterwards in the native compilation pipeline.
>
> It has an effect at runtime: Emacs needs to look up those properties
> after the byte code is evaluated. That's why .elc files have
> additional forms added which basically call 'function-put' (as set up
> in defun-declarations-alist).

Indeed it has effect in the runtime.  But as you say this is because the
byte compiler generates different code for that (in this case a top
level form).  In the case of the native compiler we'd need to store and
reuse a bunch of information for following native compilation that has
to happen after.

> But...
>
>> As the bytecompiler pipeline was always assumed to be the only and last
>> compilation step, bytecode is ATM not designed to retain these
>> information.  I'm sure it's extensible somehow but we probably need some
>> advise on what's the best way to approach this.
>
> ...I suppose you might want to access that information without
> evaluating said additional byte code forms either.
>
> Or could it evaluate them anyway? If native compilation happens after
> the code is loaded, the symbols will have the necessary properties
> then.

Maybe a sufficient solution is an ad hoc local variable emitted (when
necessary) in the .elc file with like an a-list function -> declaration
specifiers we are interested in?

  Andrea