Permalink
Commits on Dec 21, 2010
Commits on Dec 19, 2010
Commits on Dec 13, 2010
Commits on Dec 6, 2010
Commits on Nov 28, 2010
Commits on Nov 27, 2010
  1. 1.0.44.36: test case for bug #681092

    csrhodes committed Nov 27, 2010
    From the bug report.  Also remove needless quotes in some test names.
  2. 1.0.44.35: Use DX-FLET instead of FLET in WITHOUT-{INTERRUPTS,GCING}.

    Alastair Bridgewater
    Alastair Bridgewater committed Nov 27, 2010
      * 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 1.0.44.16).
  3. 1.0.44.34: gtn: KLUDGE the lambda-var assignment to not break tail-ca…

    Alastair Bridgewater
    Alastair Bridgewater committed Nov 27, 2010
    …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.
  4. 1.0.44.33: ir2tran: Correctly set up d-x closure values for tail-loca…

    Alastair Bridgewater
    Alastair Bridgewater committed Nov 27, 2010
    …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.
Commits on Nov 19, 2010
  1. 1.0.44.32: better error reporting for malformed RESTART-CASE clauses

    nikodemus committed Nov 19, 2010
      Detect missing lambda-lists.
    
      ...and missing -o to canonicalize-whitespace.
  2. 1.0.44.31: fix canonicalize-whitespace

    nikodemus committed Nov 19, 2010
     ...missing -o from last commit.
  3. 1.0.44.30: don't canonicalize whitespace in ASDF

    nikodemus committed Nov 19, 2010
      ASDF isn't that tightly coupled to SBCL anymore -- and munging
      the whitespace there just makes comparing SBCL and upstream ASDFs
      more difficult.
Commits on Nov 18, 2010
  1. 1.0.44.29: full warnings for duplicate CASE keys during SBCL build

    nikodemus committed Nov 18, 2010
      ...and fix the issue revealed.
    
      Thanks to Cyrus Harmon for the heads-up.
  2. 1.0.44.28: allow approximating unions of numeric types

    nikodemus committed Nov 18, 2010
     (dummy commit: change described here happened in the last commit really,
      but the commit message was subtly wrong and missed the version number)
    
     * 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 4 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.
  3. allow approximating unions of numeric types

    nikodemus committed Nov 18, 2010
     * 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.
Commits on Nov 16, 2010
  1. 1.0.44.26: more nuanced deprecation framework

    nikodemus committed Nov 16, 2010
     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.
  2. 1.0.44.25: don't put function leaves into the source-path when a name…

    nikodemus committed Nov 16, 2010
    … is available
    
     #<SB-C::DEFINED-FUN ...> in compiler notes is a bit hard to read, not
     to mention obscure.
  3. 1.0.44.24: tweak CAREFUL-EXPAND-MACRO

    nikodemus committed Nov 16, 2010
      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.
Commits on Nov 15, 2010
  1. 1.0.44.23: replace %METHOD-NAME and %METHOD-LAMBDA-LIST decls with sp…

    nikodemus committed Nov 15, 2010
    …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.
Commits on Nov 10, 2010
  1. 1.0.44.21: expand ~ in pathnames

    nikodemus committed Nov 10, 2010
      ~/... => (: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.
Commits on Nov 9, 2010
  1. 1.0.44.19: NEWS: Updates for changes starting at 1.0.44.6.

    Alastair Bridgewater
    Alastair Bridgewater committed Nov 9, 2010
      * EOM.
  2. 1.0.44.18: physenvanal: When checking closure-DXness, handle XEPs rea…

    Alastair Bridgewater
    Alastair Bridgewater committed Nov 9, 2010
    …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.
  3. 1.0.44.17: ir1: Declare UNWIND-PROTECT cleanup functions to be dynami…

    Alastair Bridgewater
    Alastair Bridgewater committed Nov 9, 2010
    …c-extent.
    
      * Since we now have the analysis to do the right thing
    for these functions, why not take advantage of it?
  4. 1.0.44.16: ir2tran: Don't try to stack-allocate VALUE-CELLs.

    Alastair Bridgewater
    Alastair Bridgewater committed Nov 9, 2010
      * 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.
  5. 1.0.44.15: ir2: Skip value-cell allocation where possible.

    Alastair Bridgewater
    Alastair Bridgewater committed Nov 9, 2010
      * 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.
  6. 1.0.44.14: x86-64: Implement ANCESTOR-FRAME VOPs.

    Alastair Bridgewater
    Alastair Bridgewater committed Nov 9, 2010
      * This is the x86-64 version of the "implicit" VALUE-CELL access
    for DYNAMIC-EXTENT closures.
  7. 1.0.44.13: x86: Implement ANCESTOR-FRAME VOPs.

    Alastair Bridgewater
    Alastair Bridgewater committed Nov 9, 2010
      * This is the x86 version of the "implicit" VALUE-CELL access
    for DYNAMIC-EXTENT closures.