Skip to content

Make mkFunCo take AnonArgFlags into account

Ryan Scott requested to merge wip/T21328 into master

Previously, whenever mkFunCo would produce reflexive coercions, it would use mkVisFunTy to produce the kind of the coercion. However, mkFunCo is also used to produce coercions between types of the form ty1 => ty2 in certain places. This has the unfortunate side effect of causing the type of the coercion to appear as ty1 -> ty2 in certain error messages, as spotted in #21328 (closed).

This patch address this by changing replacing the use of mkVisFunTy with mkFunctionType in mkFunCo. mkFunctionType checks the kind of ty1 and makes the function arrow => instead of -> if ty1 has kind Constraint, so this should always produce the correct AnonArgFlag. As a result, this patch fixes part (2) of #21328 (closed).

This is not the only possible way to fix #21328 (closed), as the discussion on that issue lists some possible alternatives. Ultimately, it was concluded that the alternatives would be difficult to maintain, and since we already use mkFunctionType in coercionLKind and coercionRKind, using mkFunctionType in mkFunCo is consistent with this choice. Moreover, using mkFunctionType does not regress the performance of any test case we have in GHC's test suite.

Edited by Ryan Scott

Merge request reports