* [PATCH] Print backtraces for syntax errors too.
@ 2023-02-08 15:59 Maxime Devos
2023-02-23 11:38 ` Ludovic Courtès
0 siblings, 1 reply; 7+ messages in thread
From: Maxime Devos @ 2023-02-08 15:59 UTC (permalink / raw)
To: guile-devel; +Cc: Maxime Devos
For complicated macros, especially macros that are used correctly but
have a bug in their implementation somewhere and use 'syntax-case'
or 'syntax-rules' multiple times, it can be very convenient to know
_which_ syntax-case or syntax-rules raised the syntax-error.
E.g., I'm currently debugging some changes to a (non-Guile) macro,
and I don't know what to make of the following -- the '#:getter . datum-type'
isn't even present in the original code anywhere:
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Syntax error:
unknown location: source expression failed to match any pattern in form (#:getter . datum-type)
make: *** [Makefile:1333: gnu/gnunet/dht/client.go] Fout 1
As such, partially revert the following commit that does not give a
rationale on how backtraces for syntax errors aren't helpful.
commit e0c70a8b06db2f6d721556c23280471825c3830a
Author: Andy Wingo <wingo@pobox.com>
Date: Fri Feb 11 15:16:25 2011 +0100
scm_handle_by_message uses scm_print_exception
* libguile/throw.c (handler_message, should_print_backtrace): Use
scm_print_exception. Add a helper function to determine when to print
a backtrace; don't do so on read or syntax errors.
---
libguile/throw.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/libguile/throw.c b/libguile/throw.c
index e837abe89..045759a00 100644
--- a/libguile/throw.c
+++ b/libguile/throw.c
@@ -359,8 +359,7 @@ should_print_backtrace (SCM tag, SCM stack)
&& scm_initialized_p
/* It's generally not useful to print backtraces for errors reading
or expanding code in these fallback catch statements. */
- && !scm_is_eq (tag, scm_from_latin1_symbol ("read-error"))
- && !scm_is_eq (tag, scm_from_latin1_symbol ("syntax-error"));
+ && !scm_is_eq (tag, scm_from_latin1_symbol ("read-error"));
}
static void
base-commit: 5b42f8c154906584455a4989038406c88b723cb0
prerequisite-patch-id: ba8a0acaf4d6a80a4e74ec209b127a7f34c84f69
--
2.39.1
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH] Print backtraces for syntax errors too.
2023-02-08 15:59 [PATCH] Print backtraces for syntax errors too Maxime Devos
@ 2023-02-23 11:38 ` Ludovic Courtès
2023-02-23 19:04 ` Maxime Devos
` (2 more replies)
0 siblings, 3 replies; 7+ messages in thread
From: Ludovic Courtès @ 2023-02-23 11:38 UTC (permalink / raw)
To: guile-devel
Hi,
Maxime Devos <maximedevos@telenet.be> skribis:
> For complicated macros, especially macros that are used correctly but
> have a bug in their implementation somewhere and use 'syntax-case'
> or 'syntax-rules' multiple times, it can be very convenient to know
> _which_ syntax-case or syntax-rules raised the syntax-error.
>
> E.g., I'm currently debugging some changes to a (non-Guile) macro,
> and I don't know what to make of the following -- the '#:getter . datum-type'
> isn't even present in the original code anywhere:
>
> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> Syntax error:
> unknown location: source expression failed to match any pattern in form (#:getter . datum-type)
> make: *** [Makefile:1333: gnu/gnunet/dht/client.go] Fout 1
>
> As such, partially revert the following commit that does not give a
> rationale on how backtraces for syntax errors aren't helpful.
Do you have a simple reproducer and a before/after comparison showing
what Guile prints?
Thanks,
Ludo’.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] Print backtraces for syntax errors too.
2023-02-23 11:38 ` Ludovic Courtès
@ 2023-02-23 19:04 ` Maxime Devos
2023-02-23 19:10 ` Maxime Devos
2023-02-23 19:27 ` Maxime Devos
2 siblings, 0 replies; 7+ messages in thread
From: Maxime Devos @ 2023-02-23 19:04 UTC (permalink / raw)
To: Ludovic Courtès, guile-devel
[-- Attachment #1.1.1: Type: text/plain, Size: 1126 bytes --]
On 23-02-2023 12:38, Ludovic Courtès wrote:
> Do you have a simple reproducer and a before/after comparison showing
> what Guile prints?
Simpler reproducer:
(define-syntax syntax-stuff-twice
(lambda (s)
(define (f x)
(syntax-case x ()
(#:this #''this)
(#:that #''that)))
(define (g y)
(syntax-case y ()
(#:cat #''cat)
(#:dog #''dog)))
(syntax-case s ()
((_)
;; Let's compute some syntax, for some reason.
;; (Hence, the syntax doesn't have line information
;; that might be an acceptable alternative to
;; a backtrace.)
(let ((x (datum->syntax #f "foo"))
(y (datum->syntax #f "bar")))
#`(list #,(f x) #,(g y)))))))
(syntax-stuff-twice 'this #:cat) ; <- L21
;; Before:
;; .../reproducer.scm:21:0: source expression failed to match any
pattern in form (quote this)
;;
;; After: ??? the same thing! Looks like another patch is needed.
Looks like the patch I sent doesn't actually accomplish what it was
supposed to solve ...
Greetings,
Maxime.
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] Print backtraces for syntax errors too.
2023-02-23 11:38 ` Ludovic Courtès
2023-02-23 19:04 ` Maxime Devos
@ 2023-02-23 19:10 ` Maxime Devos
2023-02-23 19:27 ` Maxime Devos
2 siblings, 0 replies; 7+ messages in thread
From: Maxime Devos @ 2023-02-23 19:10 UTC (permalink / raw)
To: Ludovic Courtès, guile-devel
[-- Attachment #1.1.1: Type: text/plain, Size: 246 bytes --]
On 23-02-2023 12:38, Ludovic Courtès wrote:
> Do you have a simple reproducer and a before/after comparison showing
> what Guile prints?
(Please ignore my previous e-mail, the reproducer was incorrect. I'll
try making another one.)
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] Print backtraces for syntax errors too.
2023-02-23 11:38 ` Ludovic Courtès
2023-02-23 19:04 ` Maxime Devos
2023-02-23 19:10 ` Maxime Devos
@ 2023-02-23 19:27 ` Maxime Devos
2023-02-24 15:48 ` Ludovic Courtès
2 siblings, 1 reply; 7+ messages in thread
From: Maxime Devos @ 2023-02-23 19:27 UTC (permalink / raw)
To: Ludovic Courtès, guile-devel
[-- Attachment #1.1.1: Type: text/plain, Size: 2212 bytes --]
On 23-02-2023 12:38, Ludovic Courtès wrote:
> Hi,
>
> Maxime Devos <maximedevos@telenet.be> skribis:
>
>> For complicated macros, especially macros that are used correctly but
>> have a bug in their implementation somewhere and use 'syntax-case'
>> or 'syntax-rules' multiple times, it can be very convenient to know
>> _which_ syntax-case or syntax-rules raised the syntax-error.
>>
>> E.g., I'm currently debugging some changes to a (non-Guile) macro,
>> and I don't know what to make of the following -- the '#:getter . datum-type'
>> isn't even present in the original code anywhere:
>>
>> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
>> Syntax error:
>> unknown location: source expression failed to match any pattern in form (#:getter . datum-type)
>> make: *** [Makefile:1333: gnu/gnunet/dht/client.go] Fout 1
>>
>> As such, partially revert the following commit that does not give a
>> rationale on how backtraces for syntax errors aren't helpful.
>
> Do you have a simple reproducer and a before/after comparison showing
> what Guile prints?
Looks like the patch didn't actually work:
(define-syntax syntax-stuff-twice
(lambda (s)
(define (process/internal object)
;; Oops! Only certain forms of 'object' were accepted.
(throw 'syntax-error "syntax-stuff-twice" "bad" '() object object))
(define (process/x x)
#`(list #,(process/internal x)))
(define (process/y y)
#`(vector #,(process/internal y)))
(define (computify o)
(datum->syntax #false o))
(syntax-case s ()
((_)
;; Let's compute some syntax, for some reason.
(let ((x (computify "imagine this syntax is very hard to follow"))
(y (computify "and difficult to distinguish from this")))
#`(list #,(process/x x) #,(process/y y)))))))
(syntax-stuff-twice)
;; Before:
;; unknown file:#f:#f: syntax-stuff-twice: bad in subform
#<syntax:reproducer.scm:15:27 "imagine this syntax is very hard to
follow"> of #<syntax:reproducer.scm:15:27 "imagine this syntax is very
hard to follow">
;; After:
;; [the same thing]
;;
;; Looks like another patch is needed ...
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] Print backtraces for syntax errors too.
2023-02-23 19:27 ` Maxime Devos
@ 2023-02-24 15:48 ` Ludovic Courtès
2023-02-24 23:38 ` Maxime Devos
0 siblings, 1 reply; 7+ messages in thread
From: Ludovic Courtès @ 2023-02-24 15:48 UTC (permalink / raw)
To: guile-devel
Maxime Devos <maximedevos@telenet.be> skribis:
> ;; Before:
> ;; unknown file:#f:#f: syntax-stuff-twice: bad in subform
> #<syntax:reproducer.scm:15:27 "imagine this syntax is very hard to
> follow"> of #<syntax:reproducer.scm:15:27 "imagine this syntax is
> very hard to follow">
> ;; After:
> ;; [the same thing]
> ;;
> ;; Looks like another patch is needed ...
What backtrace are you trying to get?
Getting a backtrace showing which macros are being expanded (similar to
what GCC does) would be great, but it’s much more work; changing this
one line in libguile won’t achieve that.
Ludo’.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] Print backtraces for syntax errors too.
2023-02-24 15:48 ` Ludovic Courtès
@ 2023-02-24 23:38 ` Maxime Devos
0 siblings, 0 replies; 7+ messages in thread
From: Maxime Devos @ 2023-02-24 23:38 UTC (permalink / raw)
To: Ludovic Courtès, guile-devel
[-- Attachment #1.1.1: Type: text/plain, Size: 3244 bytes --]
On 24-02-2023 16:48, Ludovic Courtès wrote:
> Maxime Devos <maximedevos@telenet.be> skribis:
>
>> ;; Before:
>> ;; unknown file:#f:#f: syntax-stuff-twice: bad in subform
>> #<syntax:reproducer.scm:15:27 "imagine this syntax is very hard to
>> follow"> of #<syntax:reproducer.scm:15:27 "imagine this syntax is
>> very hard to follow">
>> ;; After:
>> ;; [the same thing]
>> ;;
>> ;; Looks like another patch is needed ...
>
> What backtrace are you trying to get?
>
> Getting a backtrace showing which macros are being expanded (similar to
> what GCC does) would be great, but it’s much more work; changing this
> one line in libguile won’t achieve that.
Just a regular backtrace like Guile already makes for exceptions
unrelated to syntax, not some kind of expansion backtrace that tracks
macro expansion.
For example, let's say you have a macro that during expansion throws an
exception in some cases. For non-'syntax-error' exception types, a
backtrace is printed:
;; a.scm
(define-module (a) #:export (whatever))
(define (syntax-negate s)
(syntax-case s ()
(#false #true)
(#true #false)
(_ (error "bogus!")))) ; <--- line 6!
(define (syntax-identity s) ; identity
(syntax-case s ()
(#false #'#false)
(#true #'#true)
(_ (error "bogus!"))))
(define-syntax whatever
(lambda (s)
(syntax-case s ()
((_ x) #`(#,(syntax-negate #'x) #,(syntax-identity #'x))))))
;; b.scm
(use-modules (a))
(whatever 0)
;; Shell commands
guild compile a.scm
guild compile -L . b.scm
;; Output: a backtrace that mentions on which line of a.scm things went
wrong:
Backtrace:
[Lots of lines]
In ice-9/psyntax.scm:
[More lines]
In a.scm:
6:7 1 (_ _)
In ice-9/boot-9.scm:
1685:16 0 (raise-exception _ #:continuable? _)
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
bogus!
However, suppose I removed the (_ (error "bogus!")) lines and hence the
code produces syntax-error exceptions:
;; c.scm
(define-module (c) #:export (whatever))
(define (syntax-negate s)
(syntax-case s () ; L3
(#false #true)
(#true #false)))
(define (syntax-identity s) ; identity
(syntax-case s () ; L7
(#false #'#false)
(#true #'#true)))
(define-syntax whatever
(lambda (s)
(syntax-case s ()
((_ x) #`(#,(syntax-negate #'x) #,(syntax-identity #'x))))))
;; d.scm
(use-modules (c))
(whatever 0)
;; Shell commands
guild compile c.scm
guild compile -L . d.scm
;; Output: no backtrace at all!
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Syntax error:
d.scm:2:10: source expression failed to match any pattern in form 0
;; In case of complicated macros, it would be nice if it said _which_
;; pattern matcher failed: L3, or L7, like with a.scm+b.scm.
Summarised, I want the relatively nice backtrace that happens for
non-'syntax-error' exceptions from a.scm+b.scm (*) (it's verbose, has
lots of irrelevant stuff, but ultimately it provides an useful piece of
information: the line number on which a pattern matcher failed).
(*) Ideally you would have both the backtrace _and_ the line number in
b.scm/d.scm.
Greetings,
Maxime.
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2023-02-24 23:38 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-02-08 15:59 [PATCH] Print backtraces for syntax errors too Maxime Devos
2023-02-23 11:38 ` Ludovic Courtès
2023-02-23 19:04 ` Maxime Devos
2023-02-23 19:10 ` Maxime Devos
2023-02-23 19:27 ` Maxime Devos
2023-02-24 15:48 ` Ludovic Courtès
2023-02-24 23:38 ` Maxime Devos
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).