Tags: patch

As seen on the Dash issue tracker:

https://github.com/magnars/dash.el/issues/383

0. cd "$(mktemp -d)"
1. HOME="$PWD" XDG_CONFIG_HOME="$PWD/.config" emacs -Q
2. (setq-default
    package-archives '(("melpa" . "https://melpa.org/packages/"))
    fill-column #xffff)
3. C-x C-e
4. M-x package-install RET dash RET

Installation fails with the following in *Compile-Log*:

  Compiling file
  /tmp/tmp.IEFN9nE4Fs/.emacs.d/elpa/dash-20210704.1302/dash.el
  at Tue Jul 6 00:44:46 2021
  Entering directory
  ‘/tmp/tmp.IEFN9nE4Fs/.emacs.d/elpa/dash-20210704.1302/’
  dash.el:551:1: Error: Invalid regexp: "Invalid content of \\{\\}"

The same error occurs post-installation with 'M-x byte-compile-file' on
dash.el.  Either way, the error confusingly only shows up when Dash is
installed from MELPA:

  package-archives = '(("melpa" . "https://melpa.org/packages/"))

and not from GNU-devel ELPA:

  package-archives = '(("gnu" . "https://elpa.gnu.org/devel/"))

even though both contain identical versions of the file dash.el.  So I
guess it's some other part of the package .tar that gives rise to the
discrepancy.

Turning on debug-on-error doesn't give a backtrace, presumably because
displaying-byte-compile-warnings or similar demotes errors.

But a breakpoint in signal_or_quit reveals that
byte-compile--wide-docstring-p constructs an invalid regexp whose
repetition exceeds the new (since Emacs 27) RE_DUP_MAX limit of #xffff.

Maybe byte-compile--wide-docstring-p should defend itself against this
as follows?