fix to bytecode compiler's propoagation of local-type info
This is another old bug that could have caused validation failures
with flonums, but it showed up with fixnum tracking because fixnums
are more common (e.g., from `string-length').
There were really two bugs: information installed at the
wrong offet in one place, and a failure to detect that information
should be propagated in a different place. Fixing both avoids
a validation problem with `html/sgml-reader'.
original commit: afca33b78b
This commit is contained in:
parent
bbc7d243e9
commit
3b9e13b38f
|
@ -326,7 +326,7 @@
|
||||||
[(struct topsyntax (depth pos midpt))
|
[(struct topsyntax (depth pos midpt))
|
||||||
(list-ref/protect (glob-desc-vars globs) (+ midpt pos) 'topsyntax)]
|
(list-ref/protect (glob-desc-vars globs) (+ midpt pos) 'topsyntax)]
|
||||||
[(struct primval (id))
|
[(struct primval (id))
|
||||||
(hash-ref primitive-table id)]
|
(hash-ref primitive-table id (lambda () (error "unknown primitive")))]
|
||||||
[(struct assign (id rhs undef-ok?))
|
[(struct assign (id rhs undef-ok?))
|
||||||
`(set! ,(decompile-expr id globs stack closed)
|
`(set! ,(decompile-expr id globs stack closed)
|
||||||
,(decompile-expr rhs globs stack closed))]
|
,(decompile-expr rhs globs stack closed))]
|
||||||
|
|
Loading…
Reference in New Issue
Block a user