Both tags have a special meaning to the low-level runtime (most notably the
frame stack). Extracting them from "all symbols" is a step towards multiple
runtimes.
These function clearly operates on strings, so move them to string.d
- cl_name_char
- cl_char_name
- ecl_string_case
Add a new local assertion assert_type_radix taht uses the new type.
sq
The cmp.0077.make-load-form.circular-dep test already tried to avoid
name clashes using ext:with-clean-symbols but this is a bit
problematic to use with file compilation since it uses uninterned
symbols. Just adding a prefix avoids the issue in a simpler, more
robust way.
When we've built ECL without dynamic VV, the preprocessor define VM was
referenced in the produced header before it was defined. That lead to an error.
According to the CLHS:
> If a DEFCLASS form appears as a top level form, [...] the compiler
must make the class definition available to be returned by FIND-CLASS
when its environment argument is a value received as the environment
parameter of a macro.
We already store type definitions in the compiler environment, so we
can just reuse that.
While The metaobject protocol doesn't specify what happens when
compiling DEFCLASS, only what happens when executing it (see
https://franz.com/support/documentation/mop/concepts.html#compile-file),
real life software breaks when we try to create a full class object at
compile time. Therefore, we just create a dummy forward-referenced
class object which contains nothing more than a name.
The compiler was coercing base strings to extended strings when
encountering them as literal objects in compiled files. According to
CLHS 3.2.4.2.2, we need to preserve the actual element type (after
upgrading) of arrays during compilation. For ECL, the actual array
element type of a base-string is base-char and therefore we can't
change this to an extended string.
Actually fixing this requires some work since we use the reader to
store a printed representation of the string in the compiled file. The
reader string syntax always returns an extended string (There is a
comment in the code which claims that this is implied by CLHS 2.4.5. I
am not quite sure if that is really true but for backwards
compatibility I don't want to change this). We thus introduce a new
syntax #"..." for base strings which is used when reading objects from
compiled files. To prevent the new syntax from leaking outside of this
context, we also introduce a new readtable.
We can't pass compound function types (i.e. function types which
include argument and return types) to TYPEP. At some places, this was
already handled but not everywhere. A new function CMP-TYPEP is
introduced to handle this. At any place where a user-supplied type is
checked at compile time, we need to use CMP-TYPEP instead of TYPEP.
Dead code eliminiation often happens for automatically generated code,
so this leads to many false positives for code that doesn't have any
style issues.
Moreover, the combination of compiler-note and style-warning is
handled badly by asdf. By default, we don't display compiler-notes but
asdf catches style-warnings to display a notice that a style-warning
has been emitted which is confusing since no warning has been printed.
We need to save and restore the reference to the current function in
the environment before calling any finalizers. Otherwise, it can
happen that this is overwritten after we have set it but before
actually calling the function. This can lead to all sorts of issues
because closure environments are wrong or variadic dispatch doesn't
work correctly.
The bug appeared intermittently when compiling maxima from a version
of ECL compiled with CFLAGS="-DECL_C_COMPATIBLE_VARIADIC_DISPATCH" and
--disable-threads.
There were a number of bugs here:
- REAL was returned even for complex exponents
- The special case of exponent=0 wasn't handled correctly
- In some cases, EXPT could return integer or rational results but the
type propagator would always assume that coercion to floating point
was happening.
Examples of the bug
(expt -1.4d0 #C(1 2)) -> #C(-0.0020444484 -0.0016295447)
(expt #C(1.0 3.0) 0.0d0) -> #C(1.0 0.0)
These return a (complex single-float), should be (complex double-float).
The code incorrectly assumed that the numbers associated to the types
tx and ty were ordered such that long floats and complex long floats
have higher numbers than double floats and complex double floats.
We include captured functions, blocks and variables along with local
variables. This fixes#799.
Moreover DECODE-IHS-ENV is deperacated and more DWIM:
- calls DECODE-IHS-LOCALS for old arguments
- appends DECODE-IHS-LOCALS and DECODE-IHS-LEXENV for ihs index
DECODE-IHS-LOCALS and DECODE-IHS-LEXENV are responsible for decoding appropriate
environments.
We deprecate the function si_ihs_env in favor of more explicit si_ihs_lex and
si_ihs_lcl, but the former is left for backward compatibility with SLIME/SLYNK
because they call it to query the environment to add locals to the backtrace.
Since ~recently we store local variables in the bytevm on the stack. Also, the
native comipler under specified debug options, stores locals in ihs, but it has
nothing to do with the lexical environment. So it feels justified to push both
to a separate field.
It may seem like this proclamation is invalid sincd !346, but the divergence
happens much earlier. 8c0314022c introduces a
feature where c-compiled code can also add debug information, and in that case
the environment is a vector, so the proclamation back then should be:
(proclamation si:ihs-env (si::index) (or list vector))
Later when we've changed the representation, it should be changed to
(proclamation si:ihs-env (si::index) (or null vector))
Where NULL denotes "no lexical environment".
