fix error message on curried/uncurried signature mismatch

[tsnobip]

before this fix, error messages on curried/uncurried signature mismatch did not make sense in uncurried mode:

module Foo: { let add: (int, int) => int } = { @@uncurried.swap let add = (. a, b) => a + b }

yielded:

Signature mismatch: ... Values do not match: let add: (int, int) => int is not included in let add: (int, int) => int 

Now it yields:

 Values do not match: let add: (. int, int) => int is not included in let add: (int, int) => int 

The not so elegant part is that it means we print curried functions with a dot in uncurried mode, which might not be very clear, but I can't think of a better solution for now.

Fixes #6413

EDIT:

It now generates instead:

 Values do not match: let add: (int, int) => int (curried) is not included in let add: (int, int) => int (uncurried) 

[tsnobip]

hmm yeah it broke a test because it then reformats in uncurried mode:

ignore(. 3)

which is pretty ugly

Another solution would be to give the curry mode of the function in the signature mismatch error message when it's different from the other function (or just different from the config), something like this:

Signature mismatch: ... Values do not match: let add: (int, int) => int (curried) is not included in let add: (int, int) => int (uncurried) 

[zth]

What about special casing just this error message? Or is the code part controlling that a bit hairy perhaps?

[tsnobip]

What about special casing just this error message? Or is the code part controlling that a bit hairy perhaps?

Yeah that's what I'm trying to do:

 | Value_descriptions(id, ({ val_type = { desc = Tarrow _}} as d1), ({ val_type = { desc = Tconstr (Pident {name = "function$"},_,_)}} as d2)) -> fprintf ppf "@[<hv 2>Values do not match:@ %a@ (curied);<1 -2>is not included in@ %a@ (uncurried)]" (value_description id) d1 (value_description id) d2; show_locs ppf (d1.val_loc, d2.val_loc)

Weirdly, for some reason, this doesn't seem to work, am I not pattern matching curried and uncurried functions correctly?

@cristianoc any idea?

[zth]

@tsnobip there's this helper: Ast_uncurried_utils.typeIsUncurriedFun. Did you try matching on both combinations? Uncurried is the first type vs the last type.

[tsnobip]

@tsnobip there's this helper: Ast_uncurried_utils.typeIsUncurriedFun. Did you try matching on both combinations? Uncurried is the first type vs the last type.

hmm no I haven't tried it, thanks!

[tsnobip]

OK I solved it, the first value was wrapped inside a Tlink.

I now generate this:

 Values do not match: let add: (int, int) => int (curried) is not included in let add: (int, int) => int (uncurried) 

are we good?

[zth]

Oh, right, maybe you need to recursively dig for the actual type_expr (as in: handle Tlink, Tsubst etc). That might be safest. What do you think @cristianoc ?

Outside of that it looks fantastic!

[tsnobip]

Oh, right, maybe you need to recursively dig for the actual type_expr (as in: handle Tlink, Tsubst etc). That might be safest. What do you think @cristianoc ?

Outside of that it looks fantastic!

Yes I could easily recursively dig for that, I pushed the current version, but if you think a recursive lookup is needed, I can add it.

[zth]

Yes I could easily recursively dig for that, I pushed the current version, but if you think a recursive lookup is needed, I can add it.

@cristianoc can correct me but I think it's needed, otherwise triggering this will depend on the type checking itself (whether it's a substituted type, a link, and so on).

[zth]

There's a helper for it btw, Ctype.expand_head.

[cristianoc]

There's a helper for it btw, Ctype.expand_head.

Yes helper, no explicit recursion .

[tsnobip]

ok I'll use the helper, but I have another issue that is driving me crazy, it seems like tests of super errors are run twice with different parameters and they generate two different outputs:

 Signature mismatch: Modules do not match: { let add: (int, int) => int } is not included in { let add: (. int, int) => int } Values do not match: let add: (int, int) => int (curried) is not included in let add: (. int, int) => int (uncurried) 

or

 Signature mismatch: .... Values do not match: let add: (int, int) => int (curried) is not included in let add: (. int, int) => int (uncurried) 

So the expected files are always wrong in one of the configurations.

[zth]

Suggested change

	| { desc = Tarrow _ },
	{ desc = Tconstr (Pident {name = "function$"},_,_)} -> (" (curried)", " (uncurried)")
	| { desc = Tconstr (Pident {name = "function$"},_,_)},
	{ desc = Tarrow _ } -> (" (uncurried)", " (curried)")
	| { desc = Tarrow _ },
	t when Ast_uncurried_utils.typeIsUncurriedFun t -> (" (curried)", " (uncurried)")
	| t,
	{ desc = Tarrow _ } when Ast_uncurried_utils.typeIsUncurriedFun t -> (" (uncurried)", " (curried)")

[tsnobip]

hmm unfortunately it doesn't work with this helper, maybe it's too restrictive? Like working only on function value not on signatures maybe?

[zth]

It probably needs expand head too first, forgot about that

Edit: scratch that, already done above

[zth]

ok I'll use the helper, but I have another issue that is driving me crazy, it seems like tests of super errors are run twice with different parameters and they generate two different outputs:

 Signature mismatch: Modules do not match: { let add: (int, int) => int } is not included in { let add: (. int, int) => int } Values do not match: let add: (int, int) => int (curried) is not included in let add: (. int, int) => int (uncurried) 

or

 Signature mismatch: .... Values do not match: let add: (int, int) => int (curried) is not included in let add: (. int, int) => int (uncurried) 

So the expected files are always wrong in one of the configurations.

@cristianoc you got any idea about this?

[cristianoc]

ok I'll use the helper, but I have another issue that is driving me crazy, it seems like tests of super errors are run twice with different parameters and they generate two different outputs:

 Signature mismatch: Modules do not match: { let add: (int, int) => int } is not included in { let add: (. int, int) => int } Values do not match: let add: (int, int) => int (curried) is not included in let add: (. int, int) => int (uncurried) 

or

 Signature mismatch: .... Values do not match: let add: (int, int) => int (curried) is not included in let add: (. int, int) => int (uncurried) 

So the expected files are always wrong in one of the configurations.

@cristianoc you got any idea about this?

Not sure. Worth checking if running tests twice is intentional.

[tsnobip]

Not sure. Worth checking if running tests twice is intentional.

Ok I checked again, and the test is only run once but what happens is that it first complains that the old output is A and new is B, but if I manually change the expected file content to B, then it complains that it should be A.

This is quite confusing and frustrating, especially given that the tests pass locally.

[mununki]

I don't figure out why yet. But, it was suspicious that the error message from the ci pointed to the wrong res and expected. Therefore I tried to rename the fixtures with the shorten name and update the expected, it seems fine. #6488

EDIT:
I rename the function name in the fixtures repectively to make sure.

[zth]

Great to finally land this, good job!

[youngkidwarrior]

Also extremely happy about this because it
blocked vite HMR for me. Hopefully with this fix I can use .resi files