fix type matching failing for generic range types #853
Conversation
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
Summary ======= Fix two bugs with `typeRel` that caused no relationship to be detected when a formal range type's underlying type is dependent on an unresolved expression. Details ======= Problem One ----------- In case they hadn't been resolved yet (because they depend on late-bound type variables), the bounding values of the formal range type were *modified* when computing the relationship between two range types, which in effect meant that all following queries of the routine signature saw an instantiated range type, instead of the original generic one. The resolved expressions are now stored locally and then directly passed on to `typeRangeRel`. Problem Two ----------- Neither range-against-range nor non-range-against-range considered the case where the range's underlying type was dependent on an unresolved expression -- both returning `isNone` when the formal range type's base was a `tyFromExpr`. If the formal range type's underlying type is a `tyFromExpr`, the dependent type is now resolved first. Were `f` was used previously directly, the resolved underlying type is used instead. Tests ----- An incorrect test case from the now-working `tdependent-range_type` test is removed.
zerbina
added
bug
saem
approved these changes
Aug 23, 2023
|
/merge |
|
Merge requested by: @saem Contents after the first section break of the PR description has been removed and preserved below:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Summary
Fix two bugs with
typeRelthat caused no relationship to be detectedwhen a formal range type's underlying type is dependent on an unresolved
expression.
Details
Problem One
In case they hadn't been resolved yet (because they depend on late-bound
type variables), the bounding values of the formal range type were
modified when computing the relationship between two range types,
which in effect meant that all following queries of the routine
signature saw an instantiated range type, instead of the original
generic one.
The resolved expressions are now stored locally and then directly passed
on to
typeRangeRel.Problem Two
Neither range-against-range nor non-range-against-range considered the
case where the range's underlying type was dependent on an unresolved
expression -- both returning
isNonewhen the formal range type's baseis a
tyFromExpr.If the formal range type's underlying type is a
tyFromExpr, thedependent type is now resolved first. Were
fwas used previouslydirectly, the resolved underlying type is used instead.
Tests
An incorrect test case from the now-working
tdependent_range_typetestis removed.