Re: Docstring hack

[Stefan Monnier]

> OK, but I still lack some glue to understand the issue.  Specifically:
>
>   . the OP said "strings that are erroneously treated as docstrings in
>     dump mode" -- where's the code which makes that mistake, and how
>     is read_literal_string related to that mistake?
>   . why isn't there an alternative to fix read_literal_string not to
>     generate zero instead of the format template? the other
>     alternatives all look like partial kludges to me

In `read_literal_string` there is a hack that dates back to Emacs's
early life where we drop the string we just read and return the
0 literal instead.  We do that for those strings we think are docstrings
that will be found in etc/DOC and will be re-provided later when we call
`Snarf-documentation` (which should then replace those 0 literals with
appropriate integers pointing into etc/DOC).

The reason for this hack is to avoid allocating the string in the heap
(or worse, the purespace) since it's to be found lazily in
etc/DOC instead.

But we don't have a sure-fire way to recognize those strings, so we use
a convention that they start with "double-quote backslash newline" (this
same convention is then used in `make-docfile` in order to find those
strings).  But some non-preloaded files also use "double-quote backslash
newline" for other reasons, such as in `eieio-defclass-autoload`.

Not sure why it's a problem for Lynn, tho: he should not try to preload
`eieio-core.el` but only `eieio-core.elc` where the problem should not
appear any more.  But as noted elsewhere in Lynn's saga, the way we
currently handle `site-load.el`, those site-loaded files are also
preloaded in the `bootstrap-emacs.pdmp` (hence in their non-compiled
form), which is a bad idea.  We should fix our handling of
`site-load.el` so it's only loaded in the "final" dump after the
site-loaded files have been byte-compiled.


        Stefan