Make Object constants invisible from BasicObject
Update behavior of require_relative
Move thread under rubinius::utilities::thread
This prevents a deadlock when another thread was trying to stop the world while the environment is trying to shut down.
Correctly spec rb_str_new_cstr as 1.9-only CAPI
Currently, rb_str_new_cstr is spec'ed as a function available under both 1.8 CAPI and 1.9 CAPI in spec/ruby/optional/capi/ext/rubyspec.h. This is not true. As a version guard is correctly used in spec/ruby/optional/capi/string_spec.rb, it is only declared under 1.9 CAPI, not under 1.8 CAPI. In 1.8 mode, rb_str_new_cstr specs are only compiled, not run, thanks to the version guard. So, there is no spec failures. However, this commit suppresses the following warning from clang: spec/ruby/optional/capi/ext/string_spec.c:165:12: warning: implicit declaration of function 'rb_str_new_cstr' is invalid in C99 [-Wimplicit-function-declaration] return rb_str_new_cstr(NULL); ^ 1 warning generated. Also, #undefs aren't needed in spec/ruby/optional/capi/ext/mri.h, because rb_str_new_cstr is now correctly declared only in 1.9 CAPI.
In the Autoload parts in the VM we now do the lookup again so it's much easier to do it with the correct current scope and we follow the same lookup mechanisms as a normal constant lookup. For this we modify the Helpers for const_get so it can filter a result so the autoload is filtered and the real class or a class with the same name higher in the hierarchy is returned.
This reverts commit 2106625. This has more consequences that take a lot more effort to fix. If we want to fix this behavior we probably have to review how autoload works and change it more invasively.
This fixes cases where this scope is different from the scope where the autoload is defined.
Remove unnecessary CAPI version check from mkmf.rb's.
There is no need to check for CAPI version in mkmf.rb, since Rubinius already loaded mkmf.rb from version dependent location.
In the SignalHandler we also don't use an explicit flag to keep track of whether a thread is running so don't do it here either for consistency.
This problem could cause multiple signal handling threads. When multiple threads were exec'ing, they would all request starting and stopping the signal thread. Because we weren't locking this properly, it could happen that two signal threads were starting which causes all kinds of other problems such as deadlocking.
When multiple threads would be running sub processes with for example backticks, they could deadlock. The guard makes sure we mark the before_exec handling as gc independent so we don't deadlock.