-
Broaden the circumstances under which inaccessible code warnings are reported due to unsatisfiable constraints. Fix insoluble constraints arising from the ambiguity checker (#17295) Edited to fix an issue where these warnings would sometimes be reported in code generated by deriving declarations/clauses. There is still lots to relitigate invovling 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, where it was written in comment ghc/ghc#8392 (comment 75571) that the naive fix then made ```haskell 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, so problem avoided.
23eb4fb2
