bug#58531: 29.0.50; Wrong predicate used by map-elt gv getter

[Basil L. Contovounesios]

Stefan Monnier [2022-10-15 11:52 -0400] wrote:

>>  (defun map--plist-delete (map key)
>>    (let ((tail map) last)
>> @@ -346,7 +399,7 @@ map-contains-key
>>  If MAP is an alist, TESTFN defaults to `equal'.
>>  If MAP is a plist, `plist-member' is used instead."
>>    (if (map--plist-p map)
>> -      (plist-member map key)
>> +      (map--plist-member map key testfn)
>>      (let ((v '(nil)))
>>        (not (eq v (alist-get key map v nil (or testfn #'equal)))))))
>
> Hmmm looks like we forgot to mark the `testfn` arg obsolete here with
> `advertised-calling-convention` like we did for `map-elt`.
> Could you fix that oversight in your patch while you're at it?

Sure, but generic functions don't play well with
advertised-calling-convention: each subsequent cl-defmethod overwrites
the preceding symbol-function, so any existing entry in
advertised-signature-table is no longer found after that.

What would you propose doing?  Call set-advertised-calling-convention
after the last cl-defmethod in map.el and hope no third-party code
defines a new method?  It's not ideal, but it's better than what we
currently have.

Or is there some other trick we can employ that works in Emacs 26+?

>> -(defun eudc-plist-member (plist prop)
>> -  "Return t if PROP has a value specified in PLIST."
>> -  (if (not (= 0 (% (length plist) 2)))
>> +(defun eudc--plist-member (plist prop &optional predicate)
>> +  "Like `plist-member', but signal on invalid PLIST."
>> +  ;; Could also use `plistp', but that would change the error.
>> +  (or (zerop (% (length plist) 2))
>>        (error "Malformed plist"))
>> -  (catch 'found
>> -    (while plist
>> -      (if (eq prop (car plist))
>> -      (throw 'found t))
>> -      (setq plist (cdr (cdr plist))))
>> -    nil))
>> +  (plist-member plist prop predicate))
>
> The current error is poor (it doesn't include the offending plist, for
> example), so I think changing it (e.g. using the usual
> `wrong-type-argument` error) would be for the better.
> I do wonder whether it's worth the trouble keeping the error here, tho,
> instead of just using `plist-member` directly.

I was just being conservative, because I don't know where EUDC might get
its data from, or how important it is to catch dubious plists
red-handed.

I'd be happy to simplify the code, but let's see if Thomas (CCed) has
any comments.  Thomas, the patch touching eudc.el can be found at:
https://bugs.gnu.org/58531#8.

Thanks,

-- 
Basil