for syntax errors (i.e., exn:fail:syntax? exceptions)
Overall, it seems important to (in most cases) not show the stack that
leads to the point where raise-syntax-error is called, so as not to
confuse users who might think that that stack is useful information
in understanding how to fix the syntax error.
I've resisted this technique for avoiding those stacks for a long
time, mostly because common syntax errors in the standard settings
don't usually get the stacktrace button because they usually have
empty stacks (partly thanks to the with-stack-checkpoint dance).
But now that the underlying racket-generated stack is shown too, and
not just the errortrace-generated stack, it is harder to make those go
away. More precisely, DrRacket used to be able to rely on the fact
that files that were compiled to .zo files would not have the
instrumentation in them and thus stackframes from that code would not
show up in the stacktrace. No longer.
So, it seems time to try this alternative.
being edited in DrRacket (via places)
Added an API to let tools have access to that
information (and compute more stuff)
Used that to make an online version of Check Syntax
which led to a separately callable Check Syntax API.
`test-covered' to use just the expression -- looks like there's no
reason to use an additional key.
Also, change its uses to map each syntax to an mcons where its mcar is
used to track coverage. This is done everywhere, since it turns out to
be much faster to insert a `set-mcar!' with a 3d mpair, rather than a
call to a thunk.
Note that it still uses mpairs as a hack. It "works" in the same way
that this simplified example does:
(define-syntax m
(let ([b (mcons 0 0)])
(lambda (stx)
(with-syntax ([b b])
#'(case-lambda [() (mcar b)]
[(x) (set-mcar! b x)])))))
I think that it's fragile, and likely to stop working at some point, but
I don't see anything better for now.
