Skip to content

Ambiguity checker should not care if residual wanted constraints are insoluble

There is still lots to relitigate involing local instances, absurdity, and implication constraints, as witnessed by the thread, but I think a safe first step that fixes the original issues is removing ering on insoluble constraints even when -XAllowAmbiguousTypes is on.

As far as I can tell, this extra error checking was not done for any deap theoretical reasons, but because concerns that users would be mislead from incorrect advice in an error message. The check was added in 43856a00, which references #8392 (closed), where it was written in comment #8392 (closed) (comment 75571) that the naive fix then made

f :: Bool ~ Int => ()
f = ()

Report

Couldn't match type ‛Bool’ with ‛Int’
Inaccessible code in the type signature for f :: Bool ~ Int =>
()
To defer this ambiguity check to use sites, enable
AllowAmbiguousTypes
In the ambiguity check for: Bool ~ Int => ()
In the type signature for ‛f’: f :: Bool ~ Int => ()

It no longer does with this same change years later (with or without this PR, to be clear), so problem avoided.

  • are either individually buildable or squashed
  • have commit messages which describe what they do (referring to Notes and tickets using #NNNN syntax when appropriate)
  • have added source comments describing your change. For larger changes you likely should add a Note and cross-reference it from the relevant places.
  • add a testcase to the testsuite.
  • replace this message with a description motivating your change

If you have any questions don't hesitate to open your merge request and inquire in a comment. If your patch isn't quite done yet please do add prefix your MR title with WIP:.

Edited by John Ericson

Merge request reports