Skip to content

Fix self-type substitution for reopened generic modules - #2255

Open
marcoroth wants to merge 1 commit into
soutaro:masterfrom
marcoroth:enum-self-type
Open

Fix self-type substitution for reopened generic modules#2255
marcoroth wants to merge 1 commit into
soutaro:masterfrom
marcoroth:enum-self-type

Conversation

@marcoroth

Copy link
Copy Markdown

This pull request fixes module self-type validation when a generic module is reopened with different type parameter names.

RBS treats the type parameters of reopened declarations positionally, so declarations using E and Elem are equivalent.

Steep previously substituted every self type using the parameter names from the module's primary declaration. A self type originating from another declaration could therefore retain an unresolved type variable and incorrectly produce RBS::ModuleSelfTypeError.

The signature validator now finds the declaration that introduced each self type and uses that declaration's parameter names for substitution. A regression test covers equivalent module reopenings with differently named parameters:

module Enum[E] : _Each[E]
end

module Enum[Elem] : _Each[Elem]
end

class Collection
  include Enum[String]

  def each: () { (String) -> void } -> void
end

This also allows the RBS 4.1.2 core and shim declarations for Enumerable to be validated together.

Resolves #2254

marcoroth added a commit to marcoroth/herb that referenced this pull request Aug 3, 2026
Bump `rbs` to `4.1` and uses a `steep` fork until
soutaro/steep#2255 and
soutaro/steep#2254 are resolved.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Enumerable self-type constraint fails with RBS 4.1

1 participant