Skip to content


Subversion checkout URL

You can clone with
Download ZIP
Commits on May 29, 2015
  1. @chrisseaton
  2. @chrisseaton
  3. @chrisseaton
  4. @chrisseaton
  5. @nirvdrum
  6. @chrisseaton
  7. @chrisseaton
  8. @chrisseaton
  9. @nirvdrum
  10. @eregon
  11. @subbuss

    Fix #2993: Ensure rescue stack is properly managed in startup interp

    subbuss authored
    * The startup interpreter used to pop rescue pc entries only when
      an exception was rescued OR when the exception-end-region marker
      instruction was executed.
      However, in the no-exception case, after the ensure code is run,
      there is a jump that exits the entire rescue region. In this
      scenario, the exception-end-region marker instruction is
      completely skipped. This can be seen with this snippet below.
      When control reaches the final print, there is still a rescue
      PC on the stack. In most cases, this doesn't matter, but this is
      still a bug which is waiting to trip us up in more complex
      rescue-ensure nesting scenarios as in the bug report.
    class Foo < Exception; end
    def foo
      p 0
        p 1
        raise "whatever"
      rescue Foo
        p 2
        p 3
        p 4
      p 'boo!'
    * In this commit, I added a boolean flag to jumps that exit the
      exception region. In the startup interpreter, this flag is
      inspected to pop a rescue pc entry.
    * With this fix, I also undid my change in dbffda3 since this
      boolean flag also handles that scenario -- I should have caught
      this issue back then.
    * This issue doesn't manifest outside the startup interpreter
      because CFG construction handles everything properly and sets
      up the right rescue PCs in all scenarios.
    * I also noticed an unrelated issue -- a duplicate label was
      being emitted in ensure bodies -- I didn't investigate how/why
      this didn't cause problems during CFG construction, but evidently
      it did't.
  12. @eregon

    [Truffle] Remove (int,double) and (double,int) specializations.

    eregon authored
    * Since the additional cost of (implicitly) converting to long is low
      compared to the convert to double and floating-point operation.
  13. @nirvdrum
  14. @eregon
  15. @chrisseaton
  16. @chrisseaton
  17. @chrisseaton
  18. @mkristian

    [build] cleanup test/pom.rb

    mkristian authored
  19. @bjfish
  20. @eregon
  21. @chrisseaton
  22. @chrisseaton
  23. @eregon

    [Truffle] Rename BlockID to BreakID.

    eregon authored
    * So it makes sense to use them as well for while/until loops.
  24. @eregon
  25. @eregon
  26. @eregon
  27. @eregon
  28. @mkristian
  29. @mkristian
  30. @nirvdrum
  31. @nirvdrum
  32. @nirvdrum

    [Truffle] Ensure local assigns in argument lists are processed before…

    nirvdrum authored
    … blocks.
    If the block references the local var assigned in the argument list before the argument list is processed, it'll end up implicitly declaring a detached local variable with a default value.  When the argument list is processed, the local assign will be at a higher level and declare a local variable with the same name, but it'll be shadowed in the block since the block's local variable will be nearer in scope.
    Fixes #2999: Argument values assigned to local variables not available in block.
Commits on May 28, 2015
  1. @chrisseaton
  2. @nirvdrum

    [Truffle] Ensure block variables are looked up in the correct frame.

    nirvdrum authored
    Fixes #3001: Incorrect frame used for block variable access.
  3. @headius
Something went wrong with that request. Please try again.