Hello,

Stefan, probably,

I have found a problem while working on el-search:

The following form F:

#+begin_src emacs-lisp
(el-search--matcher
 '(or (l ^ defstruct object)
      (l ^ (and (symbol "def") (or (pred macrop) (pred special-form-p))) object))) 
#+end_src

should compile a lambda which contains a pcase form containing the given
`or' pattern:

#+begin_src emacs-lisp
(defun el-search--matcher (pattern &optional result)
  (eval
   (let ((expression (make-symbol "expression")))
     `(el-search--with-additional-pcase-macros
       (let ((byte-compile-debug t) ;make undefined pattern types raise an error
             (warning-suppress-log-types '((bytecomp)))
             (pcase--dontwarn-upats (cons '_ pcase--dontwarn-upats)))
         (byte-compile (lambda (,expression)
                         (pcase ,expression
                           (,pattern ,(or result t))
                           (_        nil)))))))))
#+end_src

where `el-search--with-additional-pcase-macros' just temporarily adds
some pattern definitions to the pcase macro environment.

The problem is that the call of `el-search--matcher' in F takes over one
minute of time and then gives up with

|  byte-compile-lapcode: Bytecode overflow

Similar cases also take extremely long also but don't cause an overflow.
AFAICT the expansion of the pattern does not produce extraordinarily
dumb code.

Even stranger: Calling `el-search--matcher' with any of the 2 patterns
inside the `or', i.e.,

#+begin_src emacs-lisp
(el-search--matcher
 '(l ^ defstruct object))
#+end_src

and

#+begin_src emacs-lisp
(el-search--macroexpand
 '(l ^ (and (symbol "def") (or (pred macrop) (pred special-form-p))) object))
#+end_src

instantly succeed.

Have I hit some weak point in the implementation of `pcase's `or'?  Is
there some way to avoid this problem?  Simplifying the semantics of `l'
seems to help a bit.  But I would like to understand what the problem is
and how I could avoid it.

This is on master, but with emacs-25 I see same issue.

Quitting with debug-on-quit -> t doesn't look like there is an infinite
recursion while compiling or code walking (though the recursion depth is
not small).

For reference I attach the macroexpansion of the pattern in F.  


Thanks,

Michael.