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

[Alan Mackenzie <acm@muc.de>]

Hello, Juri.

On Mon, Jun 24, 2019 at 00:19:22 +0300, Juri Linkov wrote:
> >> Until this is officially fixed I've come up with the following workaround,
> >> going off of the details you provided:

> >> I created a "replace_fixed.el" file in "~/.emacs.d/lisp/" that is
> >> replace.el taken from
> >> https://raw.githubusercontent.com/emacs-mirror/emacs/emacs-26/lisp/replace.el
> >> with
> >> the following diff:

> >> diff --git a/replace.el b/replace_fixed.el
> >> index 08feb8e..8280fdd 100644
> >> --- a/replace.el
> >> +++ b/replace_fixed.el
> >> @@ -2227,7 +2227,7 @@ It is called with three arguments, as if it were
> >>             (isearch-forward (not backward))
> >>             (isearch-other-end match-beg)
> >>             (isearch-error nil))
> >> -       (isearch-lazy-highlight-new-loop range-beg range-end))))
> >> +       (save-match-data (isearch-lazy-highlight-new-loop range-beg
> >> range-end)))))

> >>  (defun replace-dehighlight ()
> >>    (when replace-overlay

> >> Then I added the following to my "~/.emacs", restarted my emacs server, and
> >> the issue was gone!:

> >> (load-library "~/.emacs.d/lisp/replace_fixed.el")

> >> This probably isn't the proper fix, but just thought I'd share in case
> >> anyone else is experiencing this and wanted a temporary workaround.

> > Excellent!  To be honest, I was thinking of sending just that workaround
> > to you as a temporary patch, but it seems I didn't need to.  :-)

> > That might well be the fix we end up putting into Emacs, but it might
> > not be.  Sorry we're so slow, here.

> 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.

> 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.

> OTOH, while looking at CC-Mode I noticed that it does some matches on
> before-change hooks.

The bulk of c-before-change is inside a save-match-data, as is the bulk
of c-after-change.  Other entry points (such as
c-font-lock-fontify-region) aren't enclosed in save-match-data.

> I could debug it but can't reproduce neither in 26.1 nor in 27, even
> with -Q -nw.

For what it's worth, I only saw the bug in X Windows, immediately after
starting emacs with emacs -Q -nw.  A second try with M-% (after the first
one has failed) just works.

-- 
Alan Mackenzie (Nuremberg, Germany).