BUG: micro crashes if search query is `\Q`

[nikitax44]

steps to reproduce:

1. open any file
2. go to the end of any non-empty line
3. open find panel in regex mode
4. try to search for \Q
5. the micro will crash

Micro encountered an error: *errors.errorString regexp: Compile(`.(?:\Q)`): error parsing regexp: missing closing ): `.(?:\Q)`
regexp/regexp.go:313 (0x593cf4)
github.com/zyedidia/micro/v2/internal/buffer/search.go:45 (0x8bb84a)
github.com/zyedidia/micro/v2/internal/buffer/search.go:71 (0x8bbab0)
github.com/zyedidia/micro/v2/internal/buffer/search.go:170 (0x8bc506)
github.com/zyedidia/micro/v2/internal/action/actions.go:1122 (0x8f39f6)
github.com/zyedidia/micro/v2/internal/action/infopane.go:117 (0x90d0fb)
github.com/zyedidia/micro/v2/cmd/micro/micro.go:516 (0x947757)
github.com/zyedidia/micro/v2/cmd/micro/micro.go:455 (0x947130)
internal/runtime/atomic/types.go:194 (0x43bc2b)
runtime/asm_amd64.s:1700 (0x478d41)

If you can reproduce this error, please report it at https://github.com/zyedidia/micro/issues

[JoeKar]

While \Q compiles fine here...
https://github.com/zyedidia/micro/blob/219fb12482055312b29aa35007d0bb33ef918f30/internal/buffer/search.go#L157-L161
...it will cause trouble in the moment it is compiled a second time within these patterns here...
https://github.com/zyedidia/micro/blob/219fb12482055312b29aa35007d0bb33ef918f30/internal/buffer/search.go#L44-L50
...since every preceding character (after \Q) is considered literally instead as regex, till a \E would stop this sequence.

This is a regression of #3575, which we didn't realize before.

@matthias314:
Unfortunately I realized it here and not in the review again, that we still compile the regexp more than just once and furthermore run into trouble with the above pattern due to the usage of regexp.MustCompile() instead of regexp.Compile().

Possible patch:

diff --git a/internal/buffer/search.go b/internal/buffer/search.go
index a48e1f87..f0854272 100644
--- a/internal/buffer/search.go
+++ b/internal/buffer/search.go
@@ -17,7 +17,7 @@ const (
        padEnd
 )
 
-func findLineParams(b *Buffer, start, end Loc, i int, r *regexp.Regexp) ([]byte, int, int, *regexp.Regexp) {
+func findLineParams(b *Buffer, start, end Loc, i int, r *regexp.Regexp) ([]byte, int, int, *regexp.Regexp, error) {
        l := b.LineBytes(i)
        charpos := 0
        padMode := 0
@@ -41,15 +41,16 @@ func findLineParams(b *Buffer, start, end Loc, i int, r *regexp.Regexp) ([]byte,
                }
        }
 
+       var err error
        if padMode == padStart {
-               r = regexp.MustCompile(".(?:" + r.String() + ")")
+               r, err = regexp.Compile(".(?:" + r.String() + ")")
        } else if padMode == padEnd {
-               r = regexp.MustCompile("(?:" + r.String() + ").")
+               r, err = regexp.Compile("(?:" + r.String() + ").")
        } else if padMode == padStart|padEnd {
-               r = regexp.MustCompile(".(?:" + r.String() + ").")
+               r, err = regexp.Compile(".(?:" + r.String() + ").")
        }
 
-       return l, charpos, padMode, r
+       return l, charpos, padMode, r, err
 }
 
 func (b *Buffer) findDown(r *regexp.Regexp, start, end Loc) ([2]Loc, bool) {
@@ -68,7 +69,10 @@ func (b *Buffer) findDown(r *regexp.Regexp, start, end Loc) ([2]Loc, bool) {
        }
 
        for i := start.Y; i <= end.Y; i++ {
-               l, charpos, padMode, rPadded := findLineParams(b, start, end, i, r)
+               l, charpos, padMode, rPadded, err := findLineParams(b, start, end, i, r)
+               if err != nil {
+                       return [2]Loc{}, false
+               }
 
                match := rPadded.FindIndex(l)
 

[matthias314]

Good catch! I think it would be easiest to fix this in #3658, in the function currently named NewRegexpGroup. I'm going to push a revised version of that PR soon.

[matthias314]

I've prepared a fix as part of #3658. If you want the fix separate from that PR, let me know.

EDIT: It would be easier as part of #3658 because there the bug occurs in a function that can return regexp errors whereas in master the enclosing function cannot do that at the moment.

[niten94]

I haven't confirmed this, but I think Micro crashes like described by @JoeKar because ) isn't recognized when only adding .(: before \Q. \Qexample text itself seems to be valid, however \E might be needed when there's (.

The only solution might be displaying an error without crashing, since adjusting the regex to include \E could break something else.

[matthias314]

When I read the syntax description of Go's regular sequences, it seems to me that \Q without \E is illegal. So I would call it a bug in Go's regexp implementation. Anyway, that's what it is. I've created the PR #3914 that I think would be a quick fix. If the goal is to create a new release soon, that might be an easy solution.