Subject: bug#45576: 28.0.50 [native-comp] some functions in eshell stop functioning after commit 0593f478762437e2a8618f3f874a26424e4590b4

From: Andrea Corallo <[email-masked]>
Date: Sat, 02 Jan 2021 12:11:13 +0000

Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <[email-masked]> writes:

> "[email-masked]" <[email-masked]> writes:
>
>> Hi,
>>
>> More precisely, in this case, the "eshell-find-alias-function" definded in $EMACS_DIR/share/emacs/28.0.50/lisp/eshell/esh-cmd.el.gz seems where the issue pops up.
>>
>> Before commit #0593f478762437e2a8618f3f874a26424e4590b4,
>>
>> (eshell-find-alias-function "ls") shows
>>
>> "eshell/ls"
>>
>> but on or after commit #0593f478762437e2a8618f3f874a26424e4590b4, the same command shows
>>
>> "nil"
>>
>> Both cases are based on functions loaded from eshell.el.gz and esh-cmd.el's corresponding eln files.
>>
>> It seems that some part of the type inference code added recently lead to this unexpected result.
>>
>> Thanks,
>> Kiong-Ge.
>
> I see what's going, this is very funny :)
>
> I've used the alist producing `cl-deftype-satisfies' and reversed it to
> get the relation type-predicate -> type.
>
> But doing this way satisfying `functionp' implies the argument being a
> function (while indeed it can be also a symbol).
>
> Using this information the compiler cleverly proves the output of
> `eshell-find-alias-function' being always nil.
>
> So I guess the relation type <-> predicate in the alist used to build
> `cl-deftype-satisfies' is correct but not bijective and cannot simply be
> reversed to produce what I use.
>
> I'll come up with a fix tomorrow.

Right 43d0e8483e fix it for me, could you give a try?

Thanks!

  Andrea