bug#36328: 26.2; Args out of range on search-and-replace of *.cc file

[Juri Linkov <juri@linkov.net>]

Hello, Alan.

>> I think first we should try to narrow down the source of this match
>> data leak.
>
> Is there really such a thing as a match data leak?  I don't think there's
> any convention that the match data are preserved over large bits of code,
> particularly when different libraries are involved.  There is nothing
> documented in the Elisp manual that I can see.

Yes, it seems such match-data leak is considered at least undesirable.
I remember efforts to replace string-match with string-match-p in
potentially unsafe places and to wrap more code in save-match-data.
But I guess such efforts are futile since this task is endless.

Usually it's enough for a function that cares about preserving match-data
to protect it from mutation.

>> Then we could decide what is the best solution.  Currently I see no
>> such place in isearch-lazy-highlight-new-loop that calls external code.
>
> isearch-lazy-highlight-new-loop calls (sit-for 0), which calls redisplay,
> which calls font locking.

You are right that it's too much to expect that the match-data will be
preserved after redisplay, and we can't find and fix all places that
change match-data, so save-match-data needs be added to perform-replace
somewhere to protect match-data.

Since (sit-for 0) is unsafe for match-data, the first candidate to be
wrapped in save-match-data is (sit-for 0) itself in isearch-lazy-highlight-new-loop.

But perhaps more correct would be to use save-match-data in the same
function that cares about preserving its match-data, so the second
candidate to use save-match-data is perform-replace.  Then the need
of using save-match-data will be self-evident for everyone who will
look at the code in perform-replace: here we use match-data, and here
we protect it in the same function.