Don't transform (SYMBOL-[GLOBAL-]VALUE 'S) to a plain use of S
unless exactly semantics-preserving. It had a bunch of issues:
- it changes behavior if SYMBOL-VALUE is declared notinline
- it interacts poorly with transforms elsewhere in the compiler
that may wish to observe the call to symbol-value
and do a similar thing (to optimize the call per se)
- it's too closely tied to knowledge of how the compiler translates
"plain" uses of defvars by safely going through #'SYMBOL-VALUE.
i.e. the logic for early/late stage deprecation knows that
the compiler will ultimately call symbol-value and that a separate
warning should not be issued in ir1-convert-var
As it happens, the easiest way to avoid warning one too many times
is just use FIND-FREE-VAR to warn since it at most once (per symbol
per component) creates a hash-table entry. This also fixes the problem that
no warning was issued for SETQ and LET bindings of deprecated variables.
This approach allows a subsequent change that was hampered by deprecation
checks in the compiler macros. I also suspect that we should re-question the
decision to represent variables in final deprecation stage as symbol-macros.
* tests/deprecation.impure.lisp: tests for DEPRECATED and general
deprecation functionality
* tests/deprecation.internal.impure.lisp: tests for the internal
macros DEFINE-DEPRECATED-{FUNCTION,VARIABLE}
