* With the local functions declared to be DYNAMIC-EXTENT, the new d-x closure analysis can elide the value cells involved entirely. * This fixes lp#674458 (introduced in 220.127.116.11).
…lls. * As an utter KLUDGE, when assigning TNs for closed-over lambda variables with implicit value-cells, make the TNs component-live instead of physenv-live. This prevents any possible problems with the new physenv introduced by a tail-call overwriting the storage for the variable.
…l-calls. * Tail-local-call re-uses the current frame. It therefore needs to use the old-fp value from the current frame in EMIT-PSETQ-MOVES. * "implicit" value cells need to use the /current/ frame pointer in EMIT-PSETQ-MOVES to correctly initialize the closure. * Therefore: Add a new &optional argument to EMIT-PSETQ-MOVES for the frame-pointer to be used in closure initialization. * This fixes the obvious part of lp#681092, but unless there is a guarantee that the stack slots used for the "implicit" value cells remain unused in the tail-called function then all this does is drive the bug to become more subtle.
Detect missing lambda-lists. ...and missing -o to canonicalize-whitespace.
...and fix the issue revealed. Thanks to Cyrus Harmon for the heads-up.
* Binding *APPROXIMATE-NUMERIC-UNIONS* does that. It must be bound only by callers of TYPE-UNION that know what they want -- in general (OR (INTEGER 1 2) (INTEGER 3 4)) => (INTEGER 1 4) is wrong, as (NOT (INTEGER 1 4)) doesn't include 3. But in special cases like deriving the return type of a function it can be done. * Rename MAKE-CANONICAL-UNION-TYPE MAKE-DERIVED-UNION-TYPE, and bind *A-N-U* there if we start accumulating an overly large union of numeric types. Definition of "overly large" can be adjusted via *DERIVED-NUMERIC-UNION-COMPLEXITY-LIMIT*. * Fixes lp#309448 and the recent compiler performance regression due to new CONCATENATE deftransform as reported on sbcl-devel.
DEFINE-DEPRECATED-FUNCTION is the new one-stop shop for the "common" case of deprecating a function in favor of another one. ...in cases where it is not sufficient, call DEPRECATION-WARNING or DEPRECATION-ERROR directly from the compiler or other place. Three stages: :EARLY signals a compile-time style-warning, :LATE signals a compile-time full warning, :FINAL a compile-time full warning and a run-time error. (This is based on the assumption that this is both a sufficient and desirably nuanced taxonomy -- if more or less is wanted, changing this later is easy enough.) SB-EXT:DEPRECATION-CONDITION is the base class of all deprecation warnings and errors, but it isn't yet documented: once we have a concensus of sorts on a deprecation protocol/schedule, I will write the appropriate bits in the manual. Everything that previously had a deprecation warning is now in :LATE stage, except for INSTANCE-LAMBDA which is now in :FINAL stage.
… is available #<SB-C::DEFINED-FUN ...> in compiler notes is a bit hard to read, not to mention obscure.
Don't resignal warnings and style-warnings -- aside from the CMUCL cross-compiler KLUDGEry. They tend to be intentionally signalled by macro and compiler-macro authors, and the additional wrapper-text provided by the resignaling mostly just obfuscates the actual message. That leaves errors (and the aforementioned KLUDGE.) For these, less parentheses, more whitespace -- specifically, leave space around the actual warning/error message, instead of crowding in with the parenthetical remarks.
…ecial variables This not only simplifies PCL code, but fixes a long-standing MOP-bug and actually gives us SB-PCL:SLOW-METHOD frames in the backtraces. Previously a fairly trivial MAKE-METHOD-LAMBDA method was enough to cause (defmethod foo (x) (return-from foo t)) to break, as MAKE-METHOD-LAMBDA-INTERNAL no longer found the %METHOD-NAME declaration in the expected place, and hence was unable to add the block name.
~/... => (:ABSOLUTE :HOME ...) ~user/... => (:ABSOLUTE (:HOME "user") ...) Translation back to NAMESTRING reinstates the tilde, so we retain read/write consistency. NATIVE-NAMESTRING is responsible for getting the actual full path to specified home directory. This late resolution is necessary to have (open "~/foo") and (open #p"~/foo") open the same file in compiled code -- regardless of who compiled the file. Tilde is treated specially only at the start of the first directory component: it doesn't need to be escaped anywhere else. After trying out the various options (escape everywhere, escape in directory components, escape at the start of directory components, escape at the start of all components) this seemed both least intrusive and least ambiguous when documented -- not to mention most backwards compatible. Currently escaping the tilde does not work on Windows, but this is due to current general inability to escape the first directory component on Windows, since \\ is used also as a directory separator for non-native pathnames as well. See lp#673625. Test-case added for this. (:HOME "user") also doesn't work on Windows, which is documented in the manual.
…sonably. * In ANALYZE-INDIRECT-LAMBDA-VARS, treat functionals as being DX if either they are marked as being DX or they have a FUNCTIONAL-ENTRY-FUN that is marked as being DX. * This extends the existing logic to allow functions with XEPs (those functions callable via the full-call convention) to use the ANCESTOR-FRAME optimizations.
…c-extent. * Since we now have the analysis to do the right thing for these functions, why not take advantage of it?
* Explicit VALUE-CELLs are only used if a closure that refers to a mutable LAMBDA-VAR has indefinite extent, implying that the reference itself has indefinite extent. In such cases, dynamic extent allocation of the VALUE-CELL is contraindicated. * Remove most of the logic from EMIT-MAKE-VALUE-CELL, leaving only the statistics-tracking (EVENT) and the VOP emission, forcing the new VALUE-CELL to be heap-allocated.
* Expose the new ANCESTOR-FRAME VOPs in package-data.lisp-expr. * When creating TNs for closed-over LAMBDA-VARs with "implicit" VALUE-CELLs, force the TNs to be allocated on the control-stack, and to be live over the entire extent of the PHYSENV. * When translating a REF or SET node for such LAMBDA-VARs from a NODE in a CLAMBDA with a different PHYSENV, use the new VOPs to access the LAMBDA-VAR. * When setting up a closure for such LAMBDA-VARs from a NODE in a CLAMBDA with the same PHYSENV as the variable, use the new CLOSURE-INIT-FROM-FP VOP to stash the frame pointer instead of a VALUE-CELL or the current value of the variable. * When setting up the closure environment for a local-call that closes over such a LAMBDA-VAR, and the call is being made from a NODE in a CLAMBDA with the same PHYSENV as the variable, store the current frame-pointer instead of a VALUE-CELL or the current value of the variable.
* Add a new stage to PHYSENVANAL, after tail-annotation to fix up indirect (wanting value-cell) LAMBDA-VARs. * For each non-dynamic-extent CLAMBDA in the component, mark all of the LAMBDA-VARs as needing an explicit value cell. * This analysis is correct as far as it goes, but it turns out that marking CLAMBDAs as being dynamic-extent isn't done in several cases that one would naively expect it to, thus defeating most of the point of this analysis.
… value-cells. * Add a new EXPLICIT-VALUE-CELL attribute to the LAMBDA-VAR attributes. * Add a new LAMBDA-VAR-EXPLICIT-VALUE-CELL access macro while we're at it.