bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#46847: 28.0.50; [native-comp] assume pseudo-insns should be verified


From: Pip Cet
Subject: bug#46847: 28.0.50; [native-comp] assume pseudo-insns should be verified
Date: Fri, 5 Mar 2021 16:09:20 +0000

On Mon, Mar 1, 2021 at 1:08 PM Pip Cet <pipcet@gmail.com> wrote:
> I would like to add an optional compiler pass which asserts that the
> conditions are actually true at runtime. This is a basic safeguard
> that any assume() mechanism should have, and it's perfectly equivalent
> to the way eassume() becomes eassert() in debug builds of Emacs.

I've proceeded to change things so I can assert assumes, and here's an
incomplete list of the bugs I've found so far:

Function types:
1. append has type (function (&rest t) t), not (function (&rest list) list)
2. aref has type (function (t fixnum) t), not (function (array fixnum) t)
3. bool-vector-count-consecutive has type (function (bool-vector
boolean integer) fixnum), not (function (bool-vector bool-vector
integer) fixnum))
4. at least some of the frame-* functions accept nil parameters
5. intern-soft has type (function ((or string symbol) &optional
vector) symbol), not (function (string &optional vector) symbol)
6. length has type (function (t) integer), not (function (sequence) integer)
7. at least some of the minibuffer functions can return nil as well as a window.
8. nthcdr has type (function (integer t) t), not (function (integer list) list)
9. radians-to-degrees is a macro and probably shouldn't have a function type
10. string has type (function (&rest fixnum) string), not (function
(&rest fixnum) strng)
11. user-full-name has type (function (&optional integer) (or string
null)), not (function (&optional integer) string)

Predicate types:
1. functionp isn't equivalent to (or function symbol)

Other:
1. comp-lambda-list-gen has to allow optional arguments to be nil even
if explicitly specified.

Furthermore, I've already reported some other bugs.

So I think this is worth pursuing further.

Pip





reply via email to

[Prev in Thread] Current Thread [Next in Thread]