Fix issue with error messages for uncurried functions where expected … #5973
Conversation
This file contains 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
…and given type were swapped The logic for unification for `Function$`, which unifies with a generic uncurried type, was swapped. The error message for arity mismatch was also swapped, so those errors were showing correctly. However, in the case of expected curried function, when given a curried function whose type is begin inferred, the error message was swapped. Also added a specialized error message when the uncurried type only contains a type variable, so `$function<'a, ...>` does not leak in the output. This happens as unification failt early, and the type of the function has not been determined yet.
cristianoc
force-pushed
the
uncurried_expected
branch
from
ef6bf7b to
3cd76e2
Compare
cristianoc
commented
Feb 4, 2023
| @@ -2107,7 +2107,7 @@ and type_expect_ ?in_function ?(recarg=Rejected) env sexp ty_expected = | |||
| let state = Warnings.backup () in | |||
| let arity = Ast_uncurried.attributes_to_arity sexp.pexp_attributes in | |||
| let uncurried_typ = Ast_uncurried.make_uncurried_type ~env ~arity (newvar()) in | |||
| unify_exp_types loc env ty_expected uncurried_typ; | |||
| unify_exp_types loc env uncurried_typ ty_expected; | |||
There was a problem hiding this comment.
The expected type goes on the rhs, just like other instances in this file.
cristianoc
commented
Feb 4, 2023
| @@ -121,9 +121,9 @@ end | |||
|
|
|||
| let reportArityMismatch ~arityA ~arityB ppf = | |||
| fprintf ppf "This function expected @{<info>%s@} %s, but got @{<error>%s@}" | |||
| arityA | |||
There was a problem hiding this comment.
This was swapped, not swapping it back so it's consistent with the other error messages (A is the given one, and B is the expected).
cristianoc
commented
Feb 4, 2023
| (_, {desc = Tconstr (Pident {name = "function$"}, [{desc=Tvar _}; _],_)}) :: | ||
| (_, {desc = Tarrow _}) :: _ | ||
| ) -> | ||
| fprintf ppf "This function is an uncurried function where a curried function is expected" |
There was a problem hiding this comment.
This avoids leaking $function<'a, ...> and talks about "an uncurried function" generically.
cristianoc
commented
Feb 4, 2023
| [1;31m3[0m [2m│[0m let z1 = expectCurried([1;31m(. x, y) => x+y[0m) | ||
| 4 [2m│[0m | ||
|
|
||
| This function is an uncurried function where a curried function is expected |
There was a problem hiding this comment.
The error message used to say the exact opposite before this PR.
4 tasks
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.
…and given type were swapped
The logic for unification for
Function$, which unifies with a generic uncurried type, was swapped. The error message for arity mismatch was also swapped, so those errors were showing correctly. However, in the case of expected curried function, when given an uncurried function whose type is begin inferred, the error message was swapped.Also added a specialized error message when the uncurried type only contains a type variable, so
$function<'a, ...>does not leak in the output. This happens as unification fails early, and the type of the function has not been determined yet.