Ticket #381 (closed enhancement: fixed)

Opened 3 years ago

Last modified 8 months ago

Report the top-level binding that an error occurs in

Reported by: alaric Owned by: felix
Priority: major Milestone: 4.9.0
Component: expander Version: 4.5.0
Keywords: Cc:

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

Changed 3 years ago by felix

  • owner set to felix
  • status changed from new to assigned

Changed 3 years ago by felix

  • status changed from assigned to closed
  • resolution set to fixed

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.

Changed 2 years ago by felix

  • milestone changed from 4.7.0 to 4.8.0

Milestone 4.7.0 deleted

Changed 8 months ago by felix

  • milestone changed from 4.8.0 to 4.9.0

Milestone 4.8.0 deleted

Note: See TracTickets for help on using tickets.