Issue #18066 has been updated by jeremyevans0 (Jeremy Evans).


I think this change makes sense.  It requires quite a few test changes, though. I submitted a pull request to implement it: https://github.com/ruby/ruby/pull/4729

----------------------------------------
Bug #18066: Load did_you_mean/error_highlight even with --disable-gems
https://bugs.ruby-lang.org/issues/18066#change-93225

* Author: vo.x (Vit Ondruch)
* Status: Open
* Priority: Normal
* ruby -v: ruby 3.0.1p64 (2021-04-05 revision 0fb782ee38) [x86_64-linux]
* Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN
----------------------------------------
I guess that did_you_mean was not possible to load without RubyGems, when it used to be bundled gem. Since it is default gem, therefore part of StdLib and always available on load path, it should not be related to --disable-gems anymore.

IOW ruby.c contains this code:

~~~ruby
    if (opt->features.set & FEATURE_BIT(gems)) {
        rb_define_module("Gem");
        if (opt->features.set & FEATURE_BIT(error_highlight)) {
            rb_define_module("ErrorHighlight");
        }
        if (opt->features.set & FEATURE_BIT(did_you_mean)) {
            rb_define_module("DidYouMean");
        }
    }
~~~

while it should look like:

~~~
    if (opt->features.set & FEATURE_BIT(gems)) {
        rb_define_module("Gem");
    }

    if (opt->features.set & FEATURE_BIT(error_highlight)) {
        rb_define_module("ErrorHighlight");
    }

    if (opt->features.set & FEATURE_BIT(did_you_mean)) {
        rb_define_module("DidYouMean");
    }
~~~

(I have not checked error_highlight, but I assume it behaves similarly to did_you_mean)



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>