augment-environment generating improper signals

[Alex Plotnick]

Using the environments API from SB-CLTL2, an improper style-warning is generated for the following form:

* (augment-environment (augment-environment nil :variable '(foo))
                        :declare '((ignore foo)))
STYLE-WARNING: IGNORE declaration for an unknown variable: FOO

#S(SB-KERNEL:LEXENV ...)

A similar result occurs for function declarations.

The results are much worse for a NOTINLINE declaration:

* (augment-environment (augment-environment nil :function '(foo))
                        :declare '((notinline foo)))

debugger invoked on a UNBOUND-VARIABLE:
  The variable SB-C:*FREE-FUNS* is unbound.

Perhaps this should be a seperate bug, but it appears to be related: the environments API seems not to be hooked up in the right sort of way to the code in ir1tran.lisp that's generating these signals.

This is on SBCL 1.0.47.9.

[Nikodemus Siivola (nikodemus)]

IMO we should really implement an environment API in the core, and export it from SB-EXT -- and make SB-CLTL2 a wrapper around it providing CLTL2 compatibility in case we end up with a diffent take.

[James Kalenius (aeshtaer)]

Just ran into this doing something fairly substantial. You get the FREE-FUNS error for type declarations as well, if you don't specify :variable at the same time.

The code for parsing declarations has been, apparently since Nikodemus put it in in 002f475,

(when declare
      ;; process-decls looks in *lexenv* policy to decide what warnings to print
      (let ((*lexenv* *null-lexenv*))
        (setq env (sb-c::process-decls
                   (list `(declare ,@declare))
(lvars) (clambdas) :lexenv env :context nil))))

[James Kalenius (aeshtaer)]

Um... I posted that before I was finished and I don't see a way to edit it. Sorry.

Anyway, the comment. It suggests if you bind *lexenv* to env the signals will be more proper, and they do seem to be. The first example in the original post prints the proper "IGNORE for outer scope" warning, and free type declarations work.

It's not perfect though, the second example prints something about a compiler note variable being unbound.

This is in 1.3.3 but it's still present in 06b2113 I think.