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

From: Stefan Monnier <[email-masked]>
Date: Tue, 21 Jan 2020 14:24:23 -0500

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