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

[Dmitry Gutov]

On 30.12.2021 11:37, Andrea Corallo wrote:

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

Store in .elc files, I take it.

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

I was even going to suggest that you would parse those (byte-code ...) 
forms in compiled files -- as long as they actually vary very little, it 
could be handled by a small interpreter.

But maybe we could keep those forms uncompiled without a significant 
performance downside? Someone could benchmark that. Then the .elc files 
would just contain (function-put ...) on top-level instead.

Or if you really need the declarations available before the 
corresponding functions are defined (I don't know if you compile every 
encountered function right away, or wait until the whole file is 
parsed), the order of forms in .elc files could be swapped: first 
property declaration, then definition.