Opened 14 years ago

Closed 14 years ago

Last modified 12 years ago

#381 closed enhancement (fixed)

Report the top-level binding that an error occurs in

Reported by: Alaric Snell-Pym Owned by: felix winkelmann
Priority: major Milestone: 4.9.0
Component: expander Version: 4.5.0
Keywords: Cc:
Estimated difficulty:

Description

One bane of my life is errors like this:

Warning: reference to possibly unbound identifier: archive

Error: module unresolved: ugarit-core

...when just about *every* procedure in ugarit-core has an 'archive'
parameter. I eventually traced down the problem with a binary chop by putting deliberate references to unbound identifiers in and looking at the order of the unbound identifiers reported.

I'm not sure if line-number information persists into the expander, but I think that it should be possible to work out the name of the top-level binding (DEFINE, DEFINE-SYNTAX, or whatever) it's inside. I'm guessing that the unbound references are detected after any macros that expand *into* top-level bindings are expanded, so this mechanism would still produce useful results in such situations.

Inside the expander, ##sys#register-undefined registers undefined symbols, but it
only seems to be called by ##sys#alias-global-hook which is in turn
called only by ##sys#strip-syntax, and I'm not sufficiently versed in
Chicken internals to work out what's what above that, as it's called in
lots of places.

I see that it's called directly inside many of the core macro
definitions inside expander.scm; would it therefore suffice to define a
parameter for the "current top-level definition" and set it to the
defined name in the macro expanders for DEFINE, DEFINE-SYNTAX, and any
others, and if that parameter is not at its default value of #f, report
it in errors (and make the unbound identifier list for the module be a
list of pairs, mapping unbound identifiers to the top-level definitions
they're in?

Would that work, or is strip-syntax called in other dynamic contexts?

Change History (4)

comment:1 Changed 14 years ago by felix winkelmann

Owner: set to felix winkelmann
Status: newassigned

comment:2 Changed 14 years ago by felix winkelmann

Resolution: fixed
Status: assignedclosed

Should be better in 4.6.2. This required passing along the name of the current "containing" lambda expression inside the code-walker for the compiler and wasn't completely trivial. Apologies for the delay.

comment:3 Changed 14 years ago by felix winkelmann

Milestone: 4.7.04.8.0

Milestone 4.7.0 deleted

comment:4 Changed 12 years ago by felix winkelmann

Milestone: 4.8.04.9.0

Milestone 4.8.0 deleted

Note: See TracTickets for help on using tickets.