Re: [Chicken-hackers] [PATCH] Fix (restore?) specializations from types.db when compiling core itself

[Peter Bex]

On Sun, Dec 20, 2015 at 06:11:24PM +1300, Evan Hanson wrote:
> Unfortunately the scrutinizer change is a bit hairier. One problem is
> that it causes the "-emit-types-file" option to include system-defined
> types (i.e. those that come from from types.db) in generated .types
> files, whereas it should only include those for values defined in the
> file under compilation. That file's entries are generated by walking the
> analysis database, so I don't think we'll be able to avoid keeping track
> of whether a given type came from the user or from a types file so that
> we can determine whether to generate a type for it in this situation.

I've now added this, see the attached patch.  It simply changes the
##compiler#declared-type from a boolean to a symbol indicating the origin
of the declaration.  The code in "scrutinize" for "set!" is a bit strange
in that it seems to automatically mark variables as declared even if they
are only inferred.  I don't completely understand this code, but I've
changed the marking to be 'implicit, so that we can differentiate between
these kinds of types and types that were actually declared by the user
using "the", ":" or "(declare (type ...))" syntaxes.

To keep the behaviour consistent, now -emit-type-file emits both 'implicit
and 'local types, thereby skipping the ones loaded from the db (which have
a 'from-db marking).

> There's also now the problem of what to do when the user redefines an
> identifier without redeclaring its type. For example, with this change,
> if I redefine string-split with a different signature, csc will produce
> inaccurate scrutiny warnings because calls to *my* string-split won't
> match core's but it'll still have a declared-type, now. I haven't dug
> into this too deeply yet (I'm hoping to take a crack at these issues
> over the holidays) but I do think we'll have to make a call about what's
> correct in this and similar situations.

I really want to apply this optimization to core, so for the time being
I decided that we can do this, but only when compiling core.  That means
that core is priviliged in being able to externally declare types for a
compilation units that it will compile.  In other words, if eggs have
types files, the specializations won't be applied when compiling the egg
itself.  I think this is an acceptable compromise.

We could make this more sophisticated by allowing namespaced identifiers
(i.e., with a "module#" prefix) to be specialised when compiling the
module as well.

For CHICKEN 5, we'll always apply the specializations, because we will
not have any toplevel identifiers in types.db anymore when it is
finished.

Cheers,
Peter

0001-Mark-external-type-declarations-as-declared.chicken-5.patch
Description: Text Data

0001-Mark-external-type-declarations-as-declared.master.patch
Description: Text Data

signature.asc
Description: Digital signature