[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: native-comp-async-report-warnings-errors default value
From: |
Andrea Corallo |
Subject: |
Re: native-comp-async-report-warnings-errors default value |
Date: |
Thu, 30 Dec 2021 09:37:53 +0000 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
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
- Re: native-comp-async-report-warnings-errors default value, (continued)
- Re: native-comp-async-report-warnings-errors default value, Rudolf Adamkovič, 2021/12/17
- Re: native-comp-async-report-warnings-errors default value, Stefan Kangas, 2021/12/17
- Re: native-comp-async-report-warnings-errors default value, Po Lu, 2021/12/17
- Re: native-comp-async-report-warnings-errors default value, Andrea Corallo, 2021/12/20
- Re: native-comp-async-report-warnings-errors default value, Dmitry Gutov, 2021/12/23
- Re: native-comp-async-report-warnings-errors default value, T.V Raman, 2021/12/23
- Re: native-comp-async-report-warnings-errors default value, Andrea Corallo, 2021/12/24
- Re: native-comp-async-report-warnings-errors default value, Dmitry Gutov, 2021/12/24
- Re: native-comp-async-report-warnings-errors default value, Andrea Corallo, 2021/12/25
- Re: native-comp-async-report-warnings-errors default value, Dmitry Gutov, 2021/12/27
- Re: native-comp-async-report-warnings-errors default value,
Andrea Corallo <=
Re: native-comp-async-report-warnings-errors default value, T.V Raman, 2021/12/02