adjust compiler-macro expansion and lambda-list parsing
commit333049ee307ddeb69d4b7eee3c2a381da494da31
authorNikodemus Siivola <nikodemus@random-state.net>
Sat, 3 Dec 2011 09:37:24 +0000 (3 11:37 +0200)
committerNikodemus Siivola <nikodemus@random-state.net>
Sat, 9 Jun 2012 12:28:09 +0000 (9 15:28 +0300)
treee62bba132295f99f2dacc24e565a5a45fd4774a2
parenta0773e7d643c53e8626e49a560fb2b5ba6d8790e
adjust compiler-macro expansion and lambda-list parsing

 * Don't convert errors during compiler-macro expansion into runtime
   PROGRAM-ERRORs: signal a compile-time warning, and simply decline to expand
   the compiler-macro.

   This lives in CAREFUL-EXPAND-MACRO.

 * Make compiler not expand compiler-macros if there are arguments in keyword
   positions that are not self-evaluating constant symbols.

   This lives in two places:

    (1) VERIFY-KEYWORDS signals a COMPILER-MACRO-KEYWORD-PROBLEM when it
        encounters either an unknown keyword or anything except a
        self-evaluating symbol in a keyword position when parsing
        compiler-macro keywords.

    (2) IR1-CONVERT-FUNCTOID handles this condition by unwinding from the
        compiler-macro expansion, printing a note about the problem, and
        returning the original form.

    Calling COMPILER-MACRO-FUNCTION directly behaves exactly as before, for
    both good and ill: good in the sense that it is compliant, ill in the
    sense that doing things that way may expand things the compiler would
    decline to expand:

      (define-compiler-macro foo (&key ((a ax) t)) (format nil "a=~S" ax))

    The compiler would refuse to expand (foo a 42) unless

      (defconstant a 'a)

    had been done beforehand, but calling the COMPILER-MACRO-FUNCTION directly
    would expand it even without that -- as the spec unfortuntely requires.
NEWS
package-data-list.lisp-expr
src/code/condition.lisp
src/code/parse-defmacro.lisp
src/compiler/ir1report.lisp
src/compiler/ir1tran.lisp
tests/compiler.impure.lisp