Bug #22204: Kernel#require documentation pulls from RubyGems' version of method instead of core version (stable releases only)

• Status: Open
• Assignee: -
• Target version: -
• Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN

[maxfelsher (Max Felsher)]

Currently, https://docs.ruby-lang.org/en/4.0/Kernel.html#method-i-require shows the following text:

When RubyGems is required, Kernel#require is replaced with our own which is capable of loading gems on demand.

When you call require 'x', this is what happens:

• If the file can be loaded from the existing Ruby loadpath, it is.
• Otherwise, installed gems are searched for a file that matches. If it’s found in gem ‘y’, that gem is activated (added to the loadpath).

The normal require functionality of returning false if that file has already been loaded is preserved.

Clicking the "Source" button shows RubyGems' version of the method, with a comment indicating it was pulled from # File lib/rubygems/core_ext/kernel_require.rb, line 36.

The same situation holds for https://docs.ruby-lang.org/en/3.4/Kernel.html#method-i-require (as well as the 3.3 and 3.2 documentation, for what it's worth).

This seems to have been fixed on master: at this moment, https://docs.ruby-lang.org/en/master/Kernel.html#method-i-require shows documentation that makes more sense for a core method (starting with "Loads the given name, returning true if successful and false if the feature is already loaded"). I think the fix was in https://github.com/ruby/ruby/pull/16086, which referenced a GitHub issue describing the same problem described here.

If the backport policy allows for this kind of fix to be backported, would it be possible to fix the documentation for Ruby 4.0 and 3.4 in addition to master? (I assume this is out of scope for 3.3 and 3.2.)