summaryrefslogtreecommitdiff
path: root/spec/ruby/core
diff options
context:
space:
mode:
authornagachika <nagachika@ruby-lang.org>2023-03-25 14:25:37 +0900
committernagachika <nagachika@ruby-lang.org>2023-03-25 14:25:37 +0900
commit5c5a1135b2e688eca7dbc7ce085f37a4d9fa3fd1 (patch)
tree124217702180115e71eac2b0931173018bf974dd /spec/ruby/core
parenta308900b74ff897de50dc9c212c03daaf642f003 (diff)
merge revision(s) 790cf4b6d0475614afb127b416e87cfa39044d67: [Backport #19115]
Fix autoload status of statically linked extensions Previously, for statically-linked extensions, we used `vm->loading_table` to delay calling the init function until the extensions are required. This caused the extensions to look like they are in the middle of being loaded even before they're required. (`rb_feature_p()` returned true with a loading path output.) Combined with autoload, queries like `defined?(CONST)` and `Module#autoload?` were confused by this and returned nil incorrectly. RubyGems uses `defined?` to detect if OpenSSL is available and failed when OpenSSL was available in builds using `--with-static-linked-ext`. Use a dedicated table for the init functions instead of adding them to the loading table. This lets us remove some logic from non-EXTSTATIC builds. [Bug #19115] --- load.c | 55 +++++++++++++++++++++++++++++++++++----------- test/ruby/test_autoload.rb | 18 +++++++++++++++ vm.c | 3 +++ vm_core.h | 9 ++++++++ 4 files changed, 72 insertions(+), 13 deletions(-)
Diffstat (limited to 'spec/ruby/core')
0 files changed, 0 insertions, 0 deletions