#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
Owner: | set to felix winkelmann |
---|---|
Status: | new → assigned |
comment:2 Changed 14 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
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.