From: Jean Abou Samra <jean@abou-samra.fr>
To: 52230@debbugs.gnu.org
Subject: bug#52230: Variable not visible to compiler causes compilation failure when importing module
Date: Wed, 1 Dec 2021 22:53:56 +0100 [thread overview]
Message-ID: <24ba24dc-004e-7c00-96eb-ea2412d2e89b@abou-samra.fr> (raw)
In experiments with using guild for byte compilation
in LilyPond, I am hitting what seems like a bug. When
a variable is not defined declaratively in a way that
makes the compiler aware of it, the module it is
defined in can compile, but modules using it cannot.
Here is an example. fail.scm contains:
(define-module (fail))
variable-coming-from-somewhere-but-not-known-at-compile-time
import.scm is just:
(use-modules (fail))
Compiling fail.scm works:
$ guild compile fail.scm
fail.scm:3:0: warning: possibly unbound variable
`variable-coming-from-somewhere-but-not-known-at-compile-time'
wrote `/home/jean/.cache/guile/ccache/3.0-LE-8-4.4/.../fail.scm.go'
Compiling import.scm gives this traceback:
$ guild compile -L . import.scm
Backtrace:
In system/base/compile.scm:
327:39 19 (read-and-compile #<input: import.scm 13> #:from _ #:to …)
261:27 18 (_ _ _)
In ice-9/boot-9.scm:
2835:4 17 (save-module-excursion #<procedure 7f35bd197ea0 at lang…>)
In language/scheme/compile-tree-il.scm:
31:15 16 (_)
In ice-9/psyntax.scm:
1230:36 15 (expand-top-sequence (#<syntax:import.scm:1:0 (#<synt…>) …)
1222:19 14 (parse _ (("placeholder" placeholder)) ((top) #(# # …)) …)
259:10 13 (parse _ (("placeholder" placeholder)) (()) _ c&e (# #) #)
In ice-9/boot-9.scm:
3927:20 12 (process-use-modules _)
222:17 11 (map1 (((fail))))
3928:31 10 (_ ((fail)))
3326:17 9 (resolve-interface (fail) #:select _ #:hide _ #:prefix _ …)
In ice-9/threads.scm:
390:8 8 (_ _)
In ice-9/boot-9.scm:
3252:13 7 (_)
In ice-9/threads.scm:
390:8 6 (_ _)
In ice-9/boot-9.scm:
3536:20 5 (_)
2835:4 4 (save-module-excursion #<procedure 7f35bd260960 at ice-…>)
3556:26 3 (_)
In unknown file:
2 (primitive-load-path "fail" #<procedure 7f35bd1a0860 at…>)
In fail.scm:
3:0 1 (_)
In ice-9/boot-9.scm:
1685:16 0 (raise-exception _ #:continuable? _)
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Unbound variable:
variable-coming-from-somewhere-but-not-known-at-compile-time
I would appreciate any workarounds.
next reply other threads:[~2021-12-01 21:53 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-01 21:53 Jean Abou Samra [this message]
2022-02-19 21:08 ` bug#52230: 'guild compile' and C(++) extensions (in the context of LilyPond) Jean Abou Samra
2022-02-19 21:25 ` Olivier Dion via Bug reports for GUILE, GNU's Ubiquitous Extension Language
[not found] ` <875ypa7dm2.fsf@laura>
2022-02-22 6:34 ` Jean Abou Samra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=24ba24dc-004e-7c00-96eb-ea2412d2e89b@abou-samra.fr \
--to=jean@abou-samra.fr \
--cc=52230@debbugs.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).