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

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

[martin rudalics]

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)

Whatever that means, it makes Emacs behave erratically from now on,
like no more popping up menu bar items or not recognizing some of my
key bindings.  Quitting the debugger mitigates that but apparently
still leaves 'smerge-mode' unusable and I have to revert the buffer.
Note that all this happens in a situation where I am usually more
occupied about the reasons of the conflicts and how to resolve them
then about how the underlying resolution mechanism works.

I've been observing this behavior for years and never got around
reporting it because I always tried to understand the underlying
behaviors of 'smerge-match-conflict' and the debugger first.
Admittedly, I failed.  Does anyone have an idea about what goes on
here internally and how to fix that?

TIA, martin


In GNU Emacs 27.0.50 (build 63, x86_64-w64-mingw32)
  of 2019-12-01 built on MACHNO

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

[Stefan Kangas]

martin rudalics <rudalics@gmx.at> writes:

> 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)
>
> Whatever that means, it makes Emacs behave erratically from now on,
> like no more popping up menu bar items or not recognizing some of my
> key bindings.  Quitting the debugger mitigates that but apparently
> still leaves 'smerge-mode' unusable and I have to revert the buffer.
> Note that all this happens in a situation where I am usually more
> occupied about the reasons of the conflicts and how to resolve them
> then about how the underlying resolution mechanism works.
>
> I've been observing this behavior for years and never got around
> reporting it because I always tried to understand the underlying
> behaviors of 'smerge-match-conflict' and the debugger first.
> Admittedly, I failed.  Does anyone have an idea about what goes on
> here internally and how to fix that?
>
> TIA, martin

Copying in Stefan Monnier as the author of smerge.

Best regards,
Stefan Kangas

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

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Tue, 21 Jan 2020 14:24:23 -0500
> Cc: 38456@debbugs.gnu.org
> 
> Eli, is it OK to put it into `emacs-27`?

Yes, thanks.

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

[Stefan Monnier]

>> Eli, is it OK to put it into `emacs-27`?
> Yes, thanks.

Done,


        Stefan

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

[martin rudalics]

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

Thanks for the fix.  I'll check the next time I see a conflict.  One
thing that should be fixed too, if easily possible, is to gray out the
previous/next conflict menu entries whenever we are at the first/last
conflict.  Smerging can be a painful job (often enough I don't even know
whether the upper or lower represents the one I want to keep) so
avoiding any possible confusions should be a main goal IMHO.

martin