ruby-grape / grape / 30308956435

97%

master: 97%

Pull #2836

github

Define #hash alongside the eql?/== pairs that lacked one

Five classes alias eql? to == without defining hash: Grape::Endpoint,
Grape::Util::InheritableSetting, Grape::Middleware::Stack::Middleware,
Grape::ServeStream::StreamResponse and Grape::ServeStream::FileBody.
Ruby requires equal objects to hash alike, so each of them silently
misbehaves in a Hash, a Set or under uniq -- equal objects land in
different buckets and never dedup. Grape::Namespace and
Grape::Util::MediaType already pair the two; this brings the rest in line.

Each hash mirrors exactly what its == compares, and nothing more:

- StreamResponse / FileBody key on stream / path alone. Their == does not
  check the class, so the class stays out of the hash.
- Middleware keys on the wrapped class, which also makes it agree with the
  class itself -- something its == accepts. The superclass fallback cannot
  be honoured (a class and its superclass hash differently); it only ever
  serves #index / #include?, which compare with == rather than by hash.
- Endpoint keys on config and inheritable_setting, omitting the class,
  since its == admits a subclass through is_a? and such a pair must agree.
- InheritableSetting keys on the resolved state (#to_hash). Its == accepts
  two instances whose own stores differ as long as their chains resolve
  alike, so hashing own state would tell those apart. The same-parent fast
  path implies equal resolved state, so it agrees too. This is the cold
  path -- nothing in Grape uses a setting as a Hash key, and == keeps
  avoiding to_hash wherever it can.

No caller in Grape relies on hash lookups for these, so this closes a
latent hole rather than fixing an observed failure.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

1195 of 1284 branches covered (93.07%)

Branch coverage included in aggregate %.

3801 of 3868 relevant lines covered (98.27%)

26776.6 hits per line