It used to be: (lambda-with-lexenv () () () (lambda-list) . body)
where the first three things after lambda-with-lexenv held macros,
symbol-macros, and declarations, not necessarily in that order.
Now it is: (lambda-with-lexenv (env) (lambda-list) . body)
I don't know when this changed, but obviously we don't care too too much
if get-defined-fun is called with an incorrect lambda list of NIL.
I finally figured out why the code was so confused/confusing:
* The comment that "The only sensible thing" is the target compiler's macro
was the direct opposite of reality. The code of course did the right thing.
* The comment that "we can uncross everything" was very disingenuous,
considering that we don't uncross more than one atom per level of recursion.
* We don't _need_ to do something different for atoms when cross-compiling
- they rarely occur - however we must not compute the "slightly uncrossed"
form as (NIL) if the original was NIL, by accidentally taking car/cdr of NIL.
* After cleaning up that mess, it became evident that the non-macro case
for both + and - sb-xc-host were really nearly identical.
* Inadvertently or purposely we did not bind *TOP-LEVEL-FORM-P* to NIL for
non-toplevel code in the cross-compiler. When fixed, this bug revealed that
we expected to treat *all* DEFUNs as if toplevel, because we correctly emit
"undefined" warnings for the ones inside toplevel FLETs. make-host-1 would
resolve the warnings by loading each fasl, thus having an actual definition.
Cross-compiling can't do that, but we can whitelist those functions.
(almost-immediately-used-p lvar cast) ceases to be immediate when the
cast is deleted, add a new function, LVAR-ALMOST-IMMEDIATELY-USED-P,
which looks through casts.
Fixes lp#1811251, lp#1813036
Given:
(defstruct foo (a nil :type (or null bar))
(defstruct bar (a nil :type (or null foo))
there was no way to efficiently compile the type-check of BAR in the FOO
constructor, so it fell back to using cached-typep. Flipping the order of those
definitions doesn't help, since they're symmetric.
This change batches up forms produced by consecutive defstructs, compiling them
after digesting all the compiler metadata. It's sort of "block compilation lite"
though it's unclear if block compilation would have handled forward references
to undefined types any better than this. i.e. we might have needed this anyway,
though we pretty much gave up on block compilation, so it's irrelevant.
At the moment, no unrecognized forms may appear in between dependent defstructs;
however I think we can improve this to queue up any PROCLAIM or arbitrary DEFUN
as long as the order of compilation is preserved.
Files which are part of the build framework, namely "make-*.lisp" and anything
under src/cold except for src/cold/warm always interpret #+/- as host features,
which is obvious. In those files, the reader can't parse target feature sexprs,
but the value of SB-XC:*FEATURES* may be tested with code.
Files which are sources, namely everything else, can _only_ refer to target
features in "#+"/"#-" (sans #\!) expressions, unless within a #+(host-feature)
escape. Thus it is identical, for the time being, to using #!+ or #!-.
As far as implementation, the default *READTABLE* never has its macros changed,
so you can't just slurp a file containing target feature conditionals -
instead *READTABLE* must be bound from *XC-READTABLE*. You may continue to use
the features named :sb-xc-host and :sb-xc with either the bang or non-bang
conditional syntax. So ultimately, "#!" syntax serves no purpose at all,
and we can replace every occurrence with normal syntax.
Note also that DO-STEMS-AND-FLAGS requires a third argument to indicate whether
the flags pertain to make-host-1 or -2 which avoid erroneous injection of
the :IGNORE-FAILURE-P flag when it is intended for the host. I don't love it,
but lacking proof that the CMUCL workaround isn't needed, I preserved the
behavior while improving upon it as well.
This is a precursor to a change that will render it difficult if not impossible
to misuse "#+" or "#-" when "#!+" (resp "#!-") was intended and vice-versa.
Files that themselves are read in host mode (such as "compile-cold-sbcl") won't
have access to the target features as read suppression conditions. The features
will be present in SB-XC:*FEATURES* but without the char macros having been set.
Conversely, host features won't be testable with "#+/-" when building or running
the cross-compiler except by using the "(host-feature x)" escape syntax of the
target feature reader. In practice, such syntax is rarely called for any more.
Use a single source of truth for stack addresses and set of running threads.
The AVL tree is of the pure functional variety, and the root node is swapped
out for any insert or delete. The STACK-ALLOCATED-P function becomes safer -
at worst it sees a stale tree but never one that violates any invariants.
I do not know whether this fixes the duplicate insertion problem observed
in https://sourceforge.net/p/sbcl/mailman/message/36517264/
but it should allow us to figure out whether the problem pre-dated use of a
tree structure in the sense that tree insertion failure would happen only if
*ALL-THREADS* itself would have contained zombie threads.
I believe that to be the case, as the code for tree insert and delete were
guarded by the same critical section that guarded *ALL-THREADS*.
Therefore if deletion failed to happen in the tree for a previous thread
death, then it ought to have failed to happen in the list representations too.
Of course it's also possible that the treap code was buggy, and/or the
AVL code, but they were/are regression tested by a random tester. Another
scenario would be the code inserting a new thread somehow running before
the code deleting the old, but I don't understand in that case how you would
get a stack address that is the same, because the deletion runs on the stack
of the very thread that is dying. i.e. a physical stack is freeable only
after having removed yourself from *all-threads*. Therefore no new thread can
lay claim to that address space. I really think that if a thread died a
hard (horrible) death, it could fail to remove itself from any lists.
A final note - it seem that the "portable-threads" library directly uses
SB-THREAD::*ALL-THREADS* which is obviously wrong. If we can't find someone
to shoot, then we could rename the global var to something different,
and then (DEFINE-SYMBOL-MACRO *ALL-THREADS* (LIST-ALL-THREADS))
which restores the look-and-feel of the sb-thread internals.
(DECLAIM (TYPE (FUNCTION (T) T) *VAR*)) should allow *VAR* to be assigned
any function, though the compiler could warn if it detected something that
would definitely fail. ABOUT-TO-MODIFY-SYMBOL-VALUE was too strict, which
affected compiled PROGV and full calls to SET, and the interpreters as they
necessarily use both of those to bind or assign special variables.
Also remove spurious use of #[-+]sb-xc-host from :not-host file.
There might have been some point to having ":PURE NIL" in the past,
but it's clearly wrong, since obviously #!+cmu is and always has been false.
It would have been correct if a HAIRY-TYPE could reference mutable objects,
which it should not, nor can I see how it ever could. NEGATION-TYPE which came
from rev 58ff25d134 just borrowed the existing wrong conditional.
Incidentally, the two remaining uses of ":pure nil" to override the inherited
value of T from CTYPE seem ok or at least not wrong. MEMBER-TYPE is not
supposed to be mutable, but in the interest of safety, we might assume that
users could mutate the objects in a member-type.
Standard code can be read independently of the current package.
However, our local package nickname extension (or some reader macros,
in theory) makes it necessary to be in the correct package for
SB-IMPL::READ-MAYBE-NOTHING to do the right thing.
Implement the same logic as SWANK: we scan each line of code as a
string, ook for lines that start with "(in-package " or
"(cl:in-package ", read that line, and find the package that
corresponds to the second element in the resulting list.
Tested with a new case in sb-cover/tests.lisp.
Don't optimize m-v-bind with unused values and unknown value
producers, mv-combination needs to handle replacing unused lambda-vars
with NIL before that can e done, otherwise it can lead to type
mismatch or duplicate work.
Fixes lp#1813338
