This prevents walking C data structures concurrently, which might be in the middle of free'ing data or other non thread safe operations.
This would mean we wouldn't do the sweeping and mark rotation, causing bugs like mentioned in #2995 where we would crash with the non-concurrent GC.
Set RBX_PREFIX_PATH to the build prefix when building extensions
When building rbx with the same path settings as an already- installed rbx, it now uses the former and not the latter to build the gems. Important to have for packaging.
If we set an environment variable with a non ASCII value and we set Encoding.default_internal the program can crash. Checking for ASCII values before we proceed to encode solves the problem. I don't like using a conditional in the spec, but if we are going to use the env set by the user while running the spec suite we need to ignore some of the values.
Compare the output of MRI and Rubinius for the following script: $ cat -n proc.rb 1 class A 2 def hello 3 __method__ 4 end 5 6 def bye 7 method(__method__).to_proc 8 end 9 end 10 11 p A.new.hello 12 13 m = A.new.method(:hello) 14 p m 15 p m.source_location 16 17 prc = m.to_proc 18 p prc 19 p prc.source_location 20 21 m = A.new.method(:bye) 22 p m 23 p m.source_location 24 25 prc = A.new.bye 26 p prc 27 p prc.source_location ruby 2.1.0p0 (2013-12-25 revision 44422) [x86_64-darwin13.0] :hello #<Method: A#hello> ["proc.rb", 2] #<Proc:0x007f804c0fa338 (lambda)> ["proc.rb", 2] #<Method: A#bye> ["proc.rb", 6] #<Proc:0x007f804c0f9ed8 (lambda)> ["proc.rb", 6] rubinius 2.2.6.n78 (2.1.0 ac8f0e2f 2014-03-19 JI) [x86_64-darwin13.1.0] :hello #<Method: A#hello (defined in A at /source/rubyspec/rubyspec/proc.rb:2)> ["/source/rubyspec/rubyspec/proc.rb", 2] #<Proc:0x170@/source/rubyspec/rubyspec/proc.rb:3 (lambda)> ["/source/rubyspec/rubyspec/proc.rb", 3] #<Method: A#bye (defined in A at /source/rubyspec/rubyspec/proc.rb:6)> ["/source/rubyspec/rubyspec/proc.rb", 6] #<Proc:0x18c@/source/rubyspec/rubyspec/proc.rb:7 (lambda)> ["/source/rubyspec/rubyspec/proc.rb", 7]
This reverts commit 4b547a1. See https://www.ruby-lang.org/en/news/2014/03/10/regression-of-hash-reject-in-ruby-2-1-1/ Thanks @dbussink.
This fixes a valgrind warning on newer Linux version. It's not really a bug, but it's an easy enough workaround to fix warnings in valgrind because of strlen() usage.
Like said in #2998 (comment)...
Some minor application of DRY.
When the JIT was inlining this code: https://github.com/rails/rails/blob/4-0-stable/activerecord/lib/active_record/connection_adapters/postgresql/oid.rb#L276-290 into here: https://github.com/rails/rails/blob/4-0-stable/activerecord/lib/active_record/connection_adapters/postgresql/database_statements.rb#L136-156 the JIT was statically emitting the hash value for the key 23, so when the key 1700 was later passed, Hash#fetch was not finding the item in the Hash and triggering the 'unknown OID' warning. I'm still not certain that this optimization is sensible given that Object#hash is commonly used with Hash lookup and this basically assumes Hash keys will be homogeneous, an assumption often contravened by common Ruby code, I'm guessing.
This getter is no longer used.