Ruby — Bifrost and Ruby LSP
| Runner | Exact | Position unverified | Hard or expected gap | Unsupported | Not planned |
|---|---|---|---|---|---|
| Bifrost | 19 | 0 | 1 expected | 0 | 1 |
| Ruby LSP | 5 | 3 | 8 hard | 4 | 1 |
Bifrost corpus strengths
Section titled “Bifrost corpus strengths”Bifrost’s Ruby-specific usage graph satisfies reviewed cases involving nested
and script-level constants, superclass references, include, prepend,
extend, singleton methods and fields, instance and class variables, autoload,
generated attribute readers, method aliases, module functions, and lexical
factory constants, including the factory-return member call now promoted to an
expected baseline pass.
On the 16 shared scoreable cases, both are exact on 5, Bifrost alone is exact on 10, and neither is exact on the remaining self-construction case. Ruby LSP is position-unverified on three and hard non-exact on eight; four Declaration- oriented cases are unsupported.
Ruby contributes 10 of Bifrost’s net 20-case advantage in the secondary strict result, but only four cases to the required-destination comparison. That makes Ruby a material sensitivity of exact conformance, not a proxy for average language-server quality. The aggregate page reports the user-facing metric first and keeps equal-profile and median views so authored case counts do not provide the only weighting.
Bifrost weaknesses
Section titled “Bifrost weaknesses”ruby-require-relative-class-constructionincludes a realInvoiceself-construction that Bifrost misses.- Dynamic
public_sendremains not planned.
Bifrost therefore has stronger coverage on this fixture, but the remaining self-construction gap and not-planned dynamic dispatch prevent a claim of complete Ruby runtime modeling.
Approximation assessment
Section titled “Approximation assessment”It would be especially risky to label Ruby LSP flow- or object-insensitive from this result. The failures span constant lookup, metaprogrammed declarations, mixin precedence, aliasing, and singleton/class scopes. Several independent indexing or references-contract boundaries are more plausible than one global mechanism.
Minimal pairs should isolate direct versus factory receiver creation, lexical versus inherited constants, one mixin at a time, and generated versus explicit reader methods.
Architecture tradeoff
Section titled “Architecture tradeoff”Bifrost spends implementation complexity on explicit Ruby language facts and can expose dynamic candidates as unproven rather than definite. Ruby LSP may prioritize editor navigation surfaces and runtime-assisted workflows outside this corpus. Neither scalability nor large-application indexing cost has been compared.