GNU bug report logs - #26107
Inaccurate location info for unbound-variable errors

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: ludo <at> gnu.org (Ludovic Courtès)
Subject: bug#26107: closed (Re: Inaccurate location info for
 unbound-variable errors)
Date: Tue, 18 May 2021 20:13:01 +0000

[Message part 1 (text/plain, inline)]

Your bug report

#26107: Inaccurate location info for unbound-variable errors

which was filed against the guile package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 26107 <at> debbugs.gnu.org.

-- 
26107: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=26107
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Taylan Kammer <taylan.kammer <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 26107-done <at> debbugs.gnu.org
Subject: Re: Inaccurate location info for unbound-variable errors
Date: Tue, 18 May 2021 22:12:27 +0200

On 18.05.2021 22:11, Ludovic Courtès wrote:
> Hi,
> 
> Taylan Kammer <taylan.kammer <at> gmail.com> skribis:
> 
>> FWIW this seems fixed in 3.0, but I can reproduce with 2.2.7.
>>
>> Are we still supporting 2.2 for non-critical stuff?
> 
> There’s no plan to do so.
> 
> Ludo’.
> 

Closing then. :-)

-- 
Taylan

[Message part 3 (message/rfc822, inline)]

From: ludo <at> gnu.org (Ludovic Courtès)
To: bug-guile <at> gnu.org
Subject: Inaccurate location info for unbound-variable errors
Date: Wed, 15 Mar 2017 15:03:37 +0100

Hi!

In 2.1.8/2.2.0, walking up the stack to find the origin of an unbound
variable error yields inaccurate location info.  Consider this:

--8<---------------cut here---------------start------------->8---
(list 'a
      (symbol->string 'b)
      (symbol->string 'c)  ;← unbound variable error reported here
      (FOO 'bar)           ;… instead of here
      3
      4)
--8<---------------cut here---------------end--------------->8---

We get:

--8<---------------cut here---------------start------------->8---
$ guild compile -t value t.scm
Backtrace:
          18 (apply-smob/1 #<catch-closure 1312aa0>)
In ice-9/boot-9.scm:
    710:2 17 (call-with-prompt _ _ #<procedure default-prompt-handler (k proc)>)
In ice-9/eval.scm:
    619:8 16 (_ #(#(#<directory (guile-user) 13ba1e0>)))
In /gnu/store/4xir0dlzxl7h5v7va9rz8x3mvarlv2fd-profile/bin/guild:
    72:17 15 (main _)
In srfi/srfi-1.scm:
    640:9 14 (for-each #<procedure 128be40 at scripts/compile.scm:248:14 (file)> ("t.scm"))
In scripts/compile.scm:
   251:26 13 (_ _)
In system/base/target.scm:
     57:6 12 (with-target _ _)
In system/base/compile.scm:
    152:6 11 (compile-file "t.scm" #:output-file _ #:from _ #:to _ #:env _ #:opts _ #:canonicalization _)
     43:4 10 (call-once _)
In ice-9/boot-9.scm:
    846:4  9 (with-throw-handler _ _ _)
In system/base/compile.scm:
    59:11  8 (_)
   155:11  7 (_ #<closed: file 160a0e0>)
   224:14  6 (read-and-compile _ #:from _ #:to _ #:env _ #:opts _)
    255:6  5 (compile _ #:from _ #:to _ #:env _ #:opts _)
   183:32  4 (compile-fold _ #<tree-il (call (toplevel list) (const a) (call (toplevel symbol->string) (const b)) (call (toplevel symbol->string) (const c)) (call (toplevel FO…> …)
In ice-9/boot-9.scm:
   2309:4  3 (save-module-excursion #<procedure 1345d60 at language/bytecode/spec.scm:33:9 ()>)
In language/bytecode/spec.scm:
    35:19  2 (_)
In t.scm:
      3:6  1 (_)       ;← incorrect line number! (expected line 4)
In ice-9/boot-9.scm:
   757:25  0 (dispatch-exception _ _ _)

ice-9/boot-9.scm:757:25: In procedure dispatch-exception:
ice-9/boot-9.scm:757:25: In procedure module-lookup: Unbound variable: FOO
--8<---------------cut here---------------end--------------->8---

It Would Be Nice if we could get the right location info here, though I
understand this is a corner case.

Thoughts?

Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.