bug#38456: 27.0.50; Assertion failure in 'smerge-match-conflict'

[Stefan Monnier]

> Whenever git reports conflicts in a file, Emacs automatically enters
> 'smerge-mode' when I visit that file and moves point to the first
> conflict in its buffer.  When 'debug-on-error' is non-nil and there is
> no further conflict, typing C-c ^ n to invoke 'smerge-next' fails as
>
> Debugger entered--Lisp error: (cl-assertion-failed ((< orig-point (match-end 
> 0)) nil))
>   cl--assertion-failed((< orig-point (match-end 0)))
>   smerge-match-conflict()
>   smerge-refine()
>   smerge-next(1)
>   funcall-interactively(smerge-next 1)
>   call-interactively(smerge-next nil nil)
>   command-execute(smerge-next)

Oh, yes, thank you.  I've suffered through those many times as well ;-)
The patch below should fix it.

Eli, is it OK to put it into `emacs-27`?
OT1H it's an old bug, so there's no urgency, but OTOH it's "obviously
safe" (turns an assertion failure into a `search-failed` signal).


        Stefan


diff --git a/lisp/vc/smerge-mode.el b/lisp/vc/smerge-mode.el
index d4984bbd38..85868b91ec 100644
--- a/lisp/vc/smerge-mode.el
+++ b/lisp/vc/smerge-mode.el
@@ -797,7 +797,10 @@ smerge-match-conflict
               (filename (or (match-string 1) ""))
 
               (_ (re-search-forward smerge-end-re))
-              (_ (cl-assert (< orig-point (match-end 0))))
+              (_ (when (< (match-end 0) orig-point)
+                   ;; Point is not within the conflict we found,
+                   ;; so this conflict is not ours.
+                   (signal 'search-failed (list smerge-begin-re))))
 
               (lower-end (match-beginning 0))
               (end (match-end 0))