Tags can contain values, so let's have them contain actually useful information.
This ensures canceled builds/releases don't leave any artifacts on the current master branch.
It's no problem to fake a version.lisp-expr in the absence of git, so let's instruct the user how to do this.
This updates the SBCL build and release process to be more compatible with distributed development, specifically using git. A detailed description of what is going on here is in GIT-WORKFLOW.md. Some highlights: * Drop version.lisp-expr and branch-version.lisp-expr. * Auto-generate the version at build time using "git describe". * Update release.sh to work with git. * Make source-distribution.sh exclude the .git directory from tarballs.
* In order for a function to be returned or passed as a parameter, it must have an XEP. * Functions without XEPs, therefore, can only be called directly from within their lexical scope. They are, therefore, dynamic-extent. * But wait, you say, they could be called from a closure that is not dynamic-extent, which clearly shows such an analysis to be false. * It turns out that this doesn't matter, because the non-dynamic- extent closure also has to close over the variables passed to the supposedly-dynamic-extent closure, and that will cause explicit value-cells to be allocated anyway. * So, it's a bit of an abuse to say that the functions have dynamic extent, but it does no harm (and quite a bit of good) to treat them as if they do.
* Recent linux changes caused waitpid foreign symbol to go away so add it to undefineds and ldso-stubs * Recent linux linker default flags changes (--as-needed?) caused dlopen and friends to not be found at link time. Fix the tools-for-build/Makefile to pick up the build options from Config and fix grovel-features.sh to put the libs in LDLIBS instead of LDFLAGS
* use BACKEND_PAGE_BYTES instead of getpagesize() to match change to backend-parms in 220.127.116.11
* Setting *backend-page-bytes* to 32KB. I did test runs with different *backend-page-bytes* values and 32KB clearly came out on top performance-wise. It also delays (not avoids) the problem of running out of maximum mappings allowed by current kernel settings.
* Committing a patch I once got from Nikodemus. Without it my toy takes more than a week to compile. I've been using this since November in production, seems to work well. Should probably have made it into 18.104.22.168. ;;; FASTP is a KLUDGE: SBCL used to update the current-conflict only ;;; for the read-only case, but switched at one point to always ;;; updating it. This generally speeds up the compiler nicely, but ;;; sometimes it causes an infinite loop in the updating machinery, ;;; We cheat by switching of the fast path if it seems we're looping ;;; longer then expected.
* When setting up "environment tn conflicts", recurse through callee environments when processing a block that ends in a tail local combination and a TN that represents an "implicit" value cell. * This closes the hole where a tail-local-call would replace the stack frame which allocated a closed-over lambda-var, but the inbound stack frame didn't know about the storage for the variable, leading to badness. Hopefully the last bug with the dynamic-extent closure representation changes. * This patch fixes what 22.214.171.124 was supposed to KLUDGE around, and finishes fixing lp#681092 (the first half of the fix being 126.96.36.199).
…ional * Modified from lp#680173 by Roman Marynchak
* Patch by Jim Wise (lp#666885)
* 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 188.8.131.52).
…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.
(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.
* 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.