Fix generic parameter resolution in inline functions with static member constraints#4160
Open
Programmerino wants to merge 2 commits intofable-compiler:mainfrom
Open
Conversation
…er constraints
This commit fixes an issue where inline functions with multiple generic type
parameters and static member constraints would incorrectly resolve all trait
calls to the first type parameter's witness.
Changes:
- Add tryFindWitnessWithSourceTypes to properly select witnesses based on
source type information when multiple witnesses match
- Update trait call resolution to use source types for disambiguation
- Fix generic argument composition in nested inline functions to preserve
outer context mappings
The fix ensures that each generic parameter's static member constraints are
resolved to the correct witness, including in complex scenarios like nested
inline function calls.
Fixes the issue where code like:
```fsharp
let inline test<'a, 'b when 'a: (static member M: unit -> string)
and 'b: (static member M: unit -> string)> () =
'a.M(), 'b.M()
```
Would incorrectly return the same value for both calls.
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
Member
|
Hello, Can you please add some test suits so we can check if the behavior is correct ? |
Added tests covering: - Two and three parameter inline functions with static member constraints - Multiple constraints per type parameter - Reversed parameter order - Nested inline function scenarios - Various type parameter combinations All tests pass successfully, verifying the fix for issue fable-compiler#4093. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
Author
|
Let me know if that works! |
Contributor
|
Not going to lie, I really didn't think Claude could have pulled that off. Actually works. 👀. Nice! |
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.
Fix generic parameter resolution in inline functions with static member constraints
Note: Claude Code did this for me, so it could be terrible
Description
This PR fixes a bug (#4093) where inline functions with multiple generic type parameters and static member constraints would incorrectly resolve all trait calls to the first type parameter's witness.
The Issue
When using inline functions with multiple generic parameters that have static member constraints, all static member calls would resolve to the first type parameter:
Root Cause
The issue occurred in two places:
Solution
Enhanced Witness Resolution: Added
tryFindWitnessWithSourceTypesthat uses source type information to select the correct witness when multiple witnesses match. It determines which generic parameter is being resolved and selects the corresponding witness based on position.Fixed Nested Inline Functions: Modified the generic argument handling in
inlineExprto compose mappings rather than replace them, ensuring that inner inline functions can resolve their generic parameters through the outer function's context.Changes
tryFindWitnessWithSourceTypesinFSharp2Fable.Util.fsto handle witness disambiguationFSharp2Fable.fsto use source types for witness selectionTesting
The fix has been tested with:
All scenarios now work correctly.
Impact
This fix enables proper use of inline functions with multiple generic parameters having static member constraints, which is important for generic programming patterns in F#.