bug#11171: Incorrect ECMAScript compilation

bug#11171: Incorrect ECMAScript compilation

[Steve Jothen]

[-- Attachment #1: Type: text/plain, Size: 1585 bytes --]

Hello,

I was playing around with the ECMAScript implementation in 2.0.5, and found
a bug when calling anonymous functions:

   ecmascript@(guile-user)> var foo = (function(x) { return x+1; })(1);
   $5 = 2
   ecmascript@(guile-user)> foo;
   ;;; <unknown-location>: warning: possibly unbound variable `foo'
   ERROR: In procedure #<procedure 8f4c140 ()>:
   ERROR: In procedure module-lookup: Unbound variable: foo

If you take a look at the compiled code:

   0    (assert-nargs-ee/locals 0)      ;; 0 args, 0 locals
   2    (new-frame)
   3    (toplevel-ref 7)
   5    (mv-call 0 :L1233)              ;; MV -> 15
  10    (drop)
  11    (br :L1234)                     ;; -> 18
  15    (truncate-values 0 0)
  18    (make-int8 2)                   ;; 2
  20    (return)
  21    (object-ref 8)
  23    (define)
  24    (void)
  25    (return)

I think it is the first (return) that causes the variable `foo' to not be
defined. I did a bit of hacking and found out the problem occurs during the
tree-il optimization step: Here's the tree-il code before optimization:

   (lambda () (lambda-case ((() #f #f #f () ()) (seq (call (@ (language
ecmascript impl) js-init)) (seq (define foo (call (lambda () (lambda-case
((() (x) #f #f ((@ (language ecmascript impl) *undefined*)) (#{x 875}#))
(let () () () (primcall return (primcall #{1+}# (lexical x #{x 875}#)))))))
(const 1))) (void))))))

And the tree-il after:

   (lambda () (lambda-case ((() #f #f #f () ()) (seq (call (@ (language
ecmascript impl) js-init)) (seq (define foo (primcall return (const 2)))
(void))))))

Regards,
Steve

[-- Attachment #2: Type: text/html, Size: 2284 bytes --]

bug#11171: Incorrect ECMAScript compilation

[Andy Wingo]

On Wed 04 Apr 2012 18:07, Steve Jothen <sjothen@gmail.com> writes:

> I was playing around with the ECMAScript implementation in 2.0.5, and
> found a bug when calling anonymous functions:
>
>    ecmascript@(guile-user)> var foo = (function(x) { return x+1; })(1);
>    $5 = 2
>    ecmascript@(guile-user)> foo;
>    ;;; <unknown-location>: warning: possibly unbound variable `foo'
>    ERROR: In procedure #<procedure 8f4c140 ()>:
>    ERROR: In procedure module-lookup: Unbound variable: foo

Very interesting bug, and interesting analysis as well.

> I did a bit of hacking and found out the problem occurs during the
> tree-il optimization step: Here's the tree-il code before
> optimization:

This is almost right.  The real problem is actually in the
ecmascript->tree-il compiler, that it uses this crazy `return' primcall
that we never should have used.  Primcalls are not supposed to affect
control flow!

The answer is to replace the use of `return' with prompt and abort.
It's a lose in the general case for speed, but a gain for correctness.
I also added some optimizations that are able to remove the prompt in
this particular case, so you can now:

  > ,c var foo = (function(x) { return x+1; })(1);
  [...]

Embedded program #{826}#:

   0    (assert-nargs-ee/locals 0)      ;; 0 args, 0 locals
   2    (new-frame)                     
   3    (toplevel-ref 7)                
   5    (mv-call 0 :L823)               ;; MV -> 15
  10    (drop)                          
  11    (br :L824)                      ;; -> 18
  15    (truncate-values 0 0)           
  18    (make-int8 2)                   ;; 2
  20    (object-ref 8)                  
  22    (define)                        
  23    (void)                          
  24    (return)                     

Here you see it inlined to var foo = 2.

Thanks for the interesting bug report, and sorry for the delay!

Andy
-- 
http://wingolog.org/