-
Notifications
You must be signed in to change notification settings - Fork 470
Label name not checked and incorrect code emitted for label in external definition #7323
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Labels
Comments
In v11, the problem exists, too, and the output is function reduce(arr, initialValue, f) {
return Curry._1(arr.reduce(f), initialValue);
} |
Here's a small repro without externals: let r: (string, ~wrongLabelName: int=?) => 'a = (_s, ~wrongLabelName=3) => {
let _ = wrongLabelName
assert(false)
}
let tst1 = r("", ~initialValue=2)
let tst2 = r("")(~initialValue=2) We have that Though with the following type annotation, only let r: (string, ~wrongLabelName: int=?) => ((~initialValue:int) => int) |
cristianoc
added a commit
that referenced
this issue
Mar 13, 2025
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) ```
cristianoc
added a commit
that referenced
this issue
Mar 14, 2025
* 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) ``` * Cleanup and type errot tests.
fhammerschmidt
pushed a commit
that referenced
this issue
Apr 4, 2025
* 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) ``` * Cleanup and type errot tests.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This:
compiles fine:
However, when I change the label name:
The text was updated successfully, but these errors were encountered: