bug#41445: 26.3; Query-replace triggers "match data clobbered by..."

[Stefan Monnier]

>> > The advantage of not doing this unconditionally is that we don't
>> > unnecessarily punishing callers that don't need match-data to be
>> > saved.
>> 
>> For callers of the ucs-normalize- functions, correctness should come
>> first; their names, semantics or descriptions do not lead the user to
>> suspect them of clobbering the match data. It is an implementation leakage
>> which can be quite unexpected, as is witnessed by this bug.
>
> I thought we had some advice to Lisp programs not to assume that
> match-data will be preserved, but maybe I'm misremembering.  Stefan,
> do you remember something along these lines?

Right, we follow a convention where, by default, any function can
clobber the match-data, with just some exceptions (typically,
small/trivial functions).

>From that point of view, I see no reason why ucs-normalize-* should be
careful to preserve the match data.

This said, *if* it is the case that many/most calls to a given function
need to preserve the match-data around calls to it, it's of course
OK to simply move the match-data-saving into that function, especially
if that function's work dwarfs that of save-match-data.

I just added the following to `save-match-data`'s docstring, to try and
clarify:

    NOTE: The convention in Elisp is that any function, except for a few
    exceptions like car/assoc/+/goto-char, can clobber the match data,
    so `save-match-data' should normally be used to save *your* match
    data rather than your caller's match data.


-- Stefan