fixes #22936; Generic inheritance matching gives type mismatch when object has members#25836
Conversation
…bject has members
Contributor
There was a problem hiding this comment.
Pull request overview
This pull request fixes issue #22936 by improving the compiler’s type relationship logic so generic constraints (e.g. F: Future) accept not only direct instantiations (Future[T]) but also subtypes/descendants of that generic family, and by adding a regression test covering the scenario.
Changes:
- Extend
typeRelhandling fortyGenericBodyconstraints to recognize descendant types viaisGenericSubtype, not just directtyGenericInstmatches. - Incorporate inheritance depth into overload ranking for these generic-family descendant matches (deeper descendants become slightly less preferred).
- Add a regression test ensuring generic constraints accept subtypes of
Future[T]even when the object has members, including through a macro signature.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| compiler/sigmatch.nim | Updates typeRel for tyGenericBody constraints to accept generic-family descendants and apply inheritance-based ranking penalties. |
| tests/typerel/t8905.nim | Adds a regression test for generic subtyping with Future[T] descendants (including macro parameter matching). |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
fixes #22936
This pull request improves the compiler's handling of generic type constraints, specifically for subtypes of generics, and adds a test to cover this behavior. The main changes are an enhancement to the type relationship logic in the compiler and a new test case for generic subtyping with
Future.Compiler improvements for generic subtyping
typeRelincompiler/sigmatch.nimto allow generic constraints (likeF: Future) to accept not just direct instantiations but also descendants of the generic family, ensuring more flexible and correct overload resolution. Inheritance depth is now considered for overload ranking, making deeper descendants slightly less preferred, consistent with other inheritance-based matches.New test coverage
tests/typerel/t8905.nimto verify that generic constraints correctly accept subtypes ofFuture, including a customB[T, E] = ref object of Future[T]type, and that overloads liketake,takeMany, and the macrocheckFutureswork as expected with these types.