Allow Hash#[] to be aliased again - #6675

Summary of Changes

Hello @pzskc383, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces a critical fix to mruby by re-enabling the aliasing of the Hash#[] method. This change resolves a compatibility issue with libraries like mruby-hashie that depend on this functionality. The implementation ensures that if Hash#[] is aliased or overridden, the virtual machine correctly dispatches to the Ruby-defined method, while maintaining optimized behavior for unaliased Hash instances.

Highlights

• Re-enables Hash#[] aliasing: The pull request restores the ability to alias the Hash#[] method, which was previously prevented by a specific commit, allowing for more flexible hash manipulation.
• Fixes mruby-hashie compatibility: This change directly addresses an issue that prevented the mruby-hashie library from functioning correctly on current mruby versions, ensuring broader compatibility.
• Conditional method dispatch for Hash#[]: The virtual machine now includes a check to determine if Hash#[] has been aliased or overridden by a Ruby method. If so, it uses standard method dispatch; otherwise, it continues to use the optimized mrb_hash_get.
• New test coverage: Comprehensive test cases have been added to verify that Hash#[] can be successfully aliased for both the Hash class and its subclasses without causing crashes, confirming the intended behavior.

My concern is the performance. If we call mrb_method_search() internally here, it would be slower than normal method calls, thus this optimization become useless (at least for Hash). You have to choose between performance and flexibility here.

wouldn't it be possible to use some of the left-over flag bits of the struct RClass object to store that a class' operators (e.g. +, -, *, /, [], []=) were overriden? or have we ran out of those bits?

Thank you for the report and the PR.

I've implemented an alternative fix in commit e28372df57 that takes a different approach to balance performance and flexibility
.

The Fix

Instead of calling mrb_method_search() on every hash access (which would negate the optimization benefit), the fix checks if
the object is exactly the Hash class:

case MRB_TT_HASH:
  /* optimize only for Hash class; subclasses may override [] */
  if (mrb_obj_class(mrb, va) != mrb->hash_class) goto getidx_fallback;
  va = mrb_hash_get(mrb, va, vb);
  ...

Behavior

• Hash subclasses: Full method dispatch - can override [] freely
• Hash class itself: Uses optimized mrb_hash_get() directly

Why This Works for mruby-hashie

The mruby-hashie library uses a Mash subclass of Hash:

class Mash < Hash
  alias_method :regular_reader, :[]
  def [](key)
    # custom logic
    regular_reader(convert_key(key))
  end
end

Since Mash is a subclass, the fix ensures this pattern works correctly.

Trade-off

Overriding Hash#[] directly on the Hash class itself will not take effect:

class Hash
  def [](key); "custom"; end  # Won't be called for Hash instances
end

This is an acceptable trade-off for mruby because:

1. Subclassing is the proper OOP pattern for customization
2. Libraries like mruby-hashie already use subclasses
3. The optimization remains effective for the common case (no per-call method search overhead)

This semantic is similar to having "final" method behavior on core classes - if you need custom [] behavior, create a subclas
s.