Re: Update 1 on Bytecode Offset tracking

[Stefan Monnier <monnier@iro.umontreal.ca>]

> A hash-table seems like the most straightforward approach, which I'm
> working on now. Doing something like in the scratch/accurate-warning-pos
> branch adds a whole lot of complexity to both C and Lisp, and toggling
> byte-compilation versions of subrs feels clunky to me (though that's
> obviously just a prototype). A hash-table of conses will hopefully be
> enough, with or without the `source-map` stuff.

Preliminary measurements suggested that the hash-table way would be too slow.
But I guess it depends on the granularity.
Maybe if we only put such annotations on the "head-cons-cells", it might
be cheap enough.

> Interesting, that's not something I had thought about.  I suspect flawed
> edebug specs are common enough that this can't be relied upon.

Actually, I don't think so: since Edebug rewrites all the parts marked
as `form` or `body` with significant changes, such errors are rather
unlikely.  The more frequent problems will be when the Edebug spec is
missing or failed to mark the relevant parts as `form` or `body`, in
which case we'd not only lose the annotations (which costs us extra work
to go and remove the annotations).  But it's a "safe" form of failure
(a kind of "graceful degradation").


        Stefan