This now matches the super error that was outputted when a curried function was defined

Renamed from typeExtractUncurriedFun coreTypeExtractUncurriedFun to follow naming convention in this file. I I have redefined typeExtractUncurriedFun below. (coreTypeIsUncurriedFun is named above fore the same paramater type, and for functions with Types.type_expr as a param use typeIsUncurredFun and typeExtractUncurriedFun respectively)

Here was another gremlin I came across where you get a suggestion to unwrap your option. For the example in the tests/descriptioon you get:

  This value might need to be wrapped in a function that takes an extra
  parameter of type unit
                                                                                                                                            
  Here's the original error message
  This has type: option<'a>
  But it's expected to have type: (. unit) => option<int>
                                                                                                                                            
  Possible solutions:
  - Unwrap the option to its underlying value using `yourValue->Belt.Option.getWithDefault(someDefaultValue)`

Where the possible solution is not meant to be for functions but uncurried functions still pattern match on this case.

This was the first issue, leading to the initial bad super error being displayed. The uncurried function type would extract as a concrete variant since it matched this case when it should not.

I'm sure you've read and know more about this, but instead of throwing an exception with Not_found if uncurried, what about an implementation that extracts the uncurried case? Something like this.

if Ast_uncurried_utils.typeIsUncurriedFun ty then
   extract_concrete_variant env (Ast_uncurried.typeExtractUncurriedFun ty)
else (p0, p, cstrs)

Hey @mununki thanks for the comment! Yes I think that feel a lot nicer except that in practice it would make no difference to this function since if it is an uncurried function the extracted type would not be Type_variant? So happy to add the refactor to make it more future proof but otherwise it should never hit a case where it is an uncurried function and it can extract a concrete variant

Sorry for my misunderstanding, if so why do we need that when clause by then?

Sorry for my misunderstanding, if so why do we need that when clause by then?

It's because an uncurried function is represented by this pattern

Tconstr (Pident {name = "function$"}, [tArg; _], _)

where tArg is the underlying type of Tarrow

So when trying to extract the concrete type as a variant, it matches the case of Tconstr, but is not actually variant it's essentially just a wrapper around the underlying function. So we get a false positive.

This was the second issue where it should have given the suggestion:

  This value might need to be wrapped in a function that takes an extra
  parameter of type unit
                                                                                                                                            
  Here's the original error message
  This has type: option<'a>
  But it's expected to have type: (. unit) => option<int>
                                                                                                                                            

it only outputted

  This has type: option<'a>
  But it's expected to have type: (. unit) => option<int>

since it would not match on the cases which treat it as a function. We first need to extract the type of the uncurried function.