You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Fix issue with typing application and polymorphic types.
Fixes#7323
When typing application there's a special treatment for polymorphic types, where the arity and kinds of arguments are inferred.
For example: `f => f(~lbl1, ~lbl2)` assigns a polymorphic type `'a` to `f` initially which is then instantated to `(~lbl1:t1, ~lbl2:t2) => t3`.
That same mechanism currently applies when a function is annotated to return a polymorphic type such as `(string, ~wrongLabelName: int=?) => 'a`, where the `'a` is further instantiated to extend the function type with additional arguments.
This mechanism is OK for curried function, but incorrect for uncurried functions: while e.g. `'a => 'b` with curried function designates any function where the first argument is unlabeled, with uncurried function it only designates functions of arity 1.
So when processing application, `'b` should not be expanded further.
Two examples of problematic code that now gives type error:
```res
let r: (string, ~wrongLabelName: int=?) => 'a = (_s, ~wrongLabelName=3) => {
let _ = wrongLabelName
assert(false)
}
let tst1 = r("", ~initialValue=2)
let tst2 = r("")(~initialValue=2)
```
and
```res
let f = (_, ~def=3) => assert(false)
let g1 = f(1,2)
let g2 = f(1)(2)
```
0 commit comments