bug#27748: 26.0.50; doc strings should be in DOC file

[Stefan Kangas <stefan@marxist.se>]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Noam Postavsky <npostavs@gmail.com> writes:
>
>>> These strings still aren't in the DOC file, but I'm not sure whether
>>> that's a problem or not -- what are the practical effects of the doc
>>> string of `delete-auto-save-files' not being in that file?
>>
>> It's mostly just an optimization thing, so not hugely important (at the
>> time, Ken was working on a pure Lisp dumping strategy, so shrinking the
>> preloaded code was important for that, but we've gone with the pdumper
>> instead).  However, I seem to recall that applying something like this
>> will make it possible to solve Bug#4845, because the docstring loading
>> mechanism will no longer be reliant on finding "(defun foo" in the .elc
>> file.  So that might be nifty.
>
> Stefan M recently suggested getting rid of the DOC file entirely, so I
> wonder whether he has any comments here.  (Added to the CCs.)

FWIW, I think we should get rid of it.  Stefan M did an analysis of this
and the amount of saved memory was very small, from bytecomp.el:

  ;; For the compilation itself, we could largely get rid of this hunk-handler,
  ;; if it weren't for the fact that we need to figure out when a defalias
  ;; defines a macro, so as to add it to byte-compile-macro-environment.
  ;;
  ;; FIXME: we also use this hunk-handler to implement the function's dynamic
  ;; docstring feature.  We could actually implement it more elegantly in
  ;; byte-compile-lambda so it applies to all lambdas, but the problem is that
  ;; the resulting .elc format will not be recognized by make-docfile, so
  ;; either we stop using DOC for the docstrings of preloaded elc files (at the
  ;; cost of around 24KB on 32bit hosts, double on 64bit hosts) or we need to
  ;; build DOC in a more clever way (e.g. handle anonymous elements).