Wildcard reporting unhelpfully suppressed

NB: fixing #23223 (closed) makes the bug reported here more apparent, by breaking:

• partial-sigs/should_compile/T11192
• partial-sigs/should_fail/Defaulting1MROff
• partial-sigs/should_fail/T11122

Consider this module

{-# LANGUAGE PartialTypeSignatures #-}
module Wom where

class C a where op :: a -> a

f :: _ -> _
f x = op x

We get

Wom.hs:8:7: error: [GHC-39999]
    • No instance for ‘C w0’ arising from a use of ‘op’
    • In the expression: op x
      In an equation for ‘f’: f x = op x
  |
8 | f x = op x
  |       ^^

If we add fdefer-type-errors we get more helpful output

Wom.hs:7:6: warning: [GHC-88464] [-Wpartial-type-signatures]
    • Found type wildcard ‘_’ standing for ‘w0’
      Where: ‘w0’ is an ambiguous type variable
    • In the type signature: f :: _ -> _
  |
7 | f :: _ -> _
  |      ^

Wom.hs:7:11: warning: [GHC-88464] [-Wpartial-type-signatures]
    • Found type wildcard ‘_’ standing for ‘w0’
      Where: ‘w0’ is an ambiguous type variable
    • In the type signature: f :: _ -> _
  |
7 | f :: _ -> _
  |           ^

Wom.hs:8:7: warning: [GHC-39999] [-Wdeferred-type-errors]
    • No instance for ‘C w0’ arising from a use of ‘op’
    • In the expression: op x
      In an equation for ‘f’: f x = op x
  |
8 | f x = op x
  |       ^^

The wildcard info is very helpful in figuring out what the No instance for (C w0) stuff is about.

So what I want is this:

• to have a warning (i.e. does not kill the rest of the compilation pipeline) from the wildcards
• that is displayed even if there is also an error (in this case No instance for (C w0).

Some more detail

The type checker obediently creates messages for both (try -ddump-tc-trace to see).

But I think the error message infrastructure suppresses all warnings if there are any errors. And that is why -fdefer-type-errors (which turns type errors into warnings) allows the wildcard warnings to re-appear.

I tried and failed to find out how this suppression happens -- it's a bit of a maze. I think it may be in the mysterious and not-very-helpfully-named function GHC.Driver.Main.ioMsgMaybe, but I'm not sure.

I can't even find where GHC.Tc.Errors.reportHoles decides the severity of the message. I thought it was in the call to diagReasonSeverity in that function; but no: that severity is used briefly to filter out some holes. Instead, it must be somewhere inside mkHoleError, or perhaps mkErrorReport, but (discouragingly) I could not find where.

I rather suspect that the infrastructure simply can't deal with

• a warning (i.e. does not kill the rest of the compilation pipeline)...
• that is displayed even if there is also an error.

Maybe we need an extra constructor in Severity for "warnings that should displayed with errors, but which don't kill compilation"?

This bump in the road is what is causing a couple of regressions in !10123 (merged), which I am eager to land. But it's not restricted to !10123 (merged). The above problem is in HEAD today.