Re: Introducing 'safety' compilation parameter

[Andrea Corallo]

Andrea Corallo <acorallo@gnu.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Andrea Corallo <acorallo@gnu.org>
>>> Cc: Eli Zaretskii <eliz@gnu.org>, monnier@iro.umontreal.ca,
>>>  mattias.engdegard@gmail.com, stefankangas@gmail.com
>>> Date: Tue, 07 May 2024 06:37:50 -0400
>>> 
>>> I've put in scratch/comp-safety a branch wich introduces 'safety' as
>>> compilation parameter.
>>> 
>>> 'safety' can be used similarly to 'native-comp-speed' both as a global
>>> variable to influence compilation both as a function declaration.
>>> 
>>> 'safety' justification of existence is ATM being able to control the
>>> undefined behaviour being created when function type declaration added
>>> by the user is not correct.
>>> 
>>> ATM we can have two values:
>>> 
>>> 1 Emitted code is generated in a safe matter even if function types are
>>> miss-declared.
>>> 0 Emitted code can misbehave or crash Emacs if function declarations are
>>> not correct and the function is native compiled (@pxref{Native
>>> Compilation}).
>>> 
>>> 1 is ATM the default.
>>
>> Is this for Emacs 30 or Emacs 31?
>>
>> If the former, we should conclude this discussion soon enough.
>>
>> I don't have an opinion about the utility of this for Emacs Lisp, but
>> this part of the documentation:
>>
>>> +Possible values are:
>>> +
>>> +0 Emitted code can misbehave or crash Emacs if function declarations are
>>> +not correct and the function is native compiled (@pxref{Native
>>> +Compilation}).
>>> +
>>> +1 Emitted code is generated in a safe matter even if function are
>>> +miss-declared."
>>
>> should be formatted as a @table.
>
> Okay, I moved that part to doc/lispref/compile.texi to document in
> 'compilation-safety' and added the @table for the possible values.
> Still in functions.texi we keep a reference to it.

Sorry forgot to mention that the new code is in scratch/comp-safety2
(I'll do some GC at the end but wanted to keep both approaches for now).

Thanks

  Andrea