so rspec can correctly report errors
* The size is known beforehand.
* Otherwise just -ea does not work anymore (but -esa or -ea:org.jruby.truffle... would)
... as it might not have been initialized (code gets more predictable)
* jruby-1_7: close JRuby's class-loader resources on Java 7+ (but only in embed uses) make fields final revert "close (URLClassLoader's) resources on JRubyClassLoader#tearDown" Conflicts: core/src/main/java/org/jruby/Ruby.java core/src/main/java/org/jruby/embed/ScriptingContainer.java core/src/main/java/org/jruby/util/JRubyClassLoader.java
... for other uses users can now manually trigger a releaseJRubyClassLoader
reverts commit: 2b28036
When looking up a method with `respond_to?`, the caller is `respond_to?` itself, which will be able to see all methods on the receiver. What we really want to check is the caller of `respond_to?` so we need to look up at the caller frame.
The following fixes were made: 1. Same kind of fix as in d59eeec but applied to this pass. The actual addition of binding stores shouldn't do additional analysis not already present in the dataflow analysis. It should simply use information from that analysis and add stores, where required. 2. A specific outcome of 1. above is: the addition should not look at scope type while adding stores on exit. If the analysis says: "add a store", add a store. No need to do it for closures only. 3. There was a subtle bug in the code. For exit BBs, we were intersecting lvars that were dirtied with lvars that were live at that point. However, we were looking for 'varsLiveOnExit' which was erroneous. LVA is a backwards propagation problem and we should be looking at 'varsLiveOnEntry' (since the exit of the scope corresponds to the dataflow entry for LVA). Between these fixes and the fix in 8c48c3bc, #3173 should be solved.
DCE used to do additional tests to decide if an instruction can be deleted based on the scope's state. This is a no-no. DCE should not do any additional tests about deletability based on scope state (which was in reality liveness tests) -- it should simply use whatever info is produced by LVA. Those tests should have been part of LVA instead. This really didn't affect correctness of DCE, but it would be providing incorrect information about vars still live when the scope was exited. Specifically, AddLocalVarLoadStoreInstructions pass uses that LVA information to determine whether to add lvar stores on exit. Without accurate LVA information, this can inadvertently prevent lvar updates from being seen outside the scope. This is part 1 of the fix for #3173.