Looking for feedback:

We'd love to have IDE diagnostics for things detected in refchecks even when typer reported errors. (also see scala/scala3#22872). For example, we have users used to seeing missing implementations for abstract methods in Scala 2 IntelliJ diagnostics, but missing them via metals.

I ran an expertiment running refchecks after typer reported errors and got the relevant test to pass. I want to share the results of the experiment. Please let me know if this sounds worth it for me to further pursue and polish.

Motivation: Running refchecks unlocks the following diagnostics even when having type errors.

• error: object creation impossible.
  Missing implementation:
  def …: … = ??? // variables need to be initialized to be defined
• error: method … overrides nothing
• error: in … multiple overloaded alternatives of method … define default arguments.
• error: @throws only allowed for methods and constructors
• error: Java annotation … may not appear multiple times on method …
• error: incompatible type in overriding
• error: illegal inheritance;
  trait … inherits different type instances of trait …:
• error: covariant type … occurs in contravariant position in type … of method …
• error: object … in package … is marked @experimental and therefore its enclosing scope must be experimental.
• error: cannot override final member
• warning: shadowing a nested class of a parent is deprecated but class … shadows class … defined in class …; rename the class to something else
• warning: value … in class … does nothing other than call itself recursively
• warning: method… is deprecated (since …): …
• warning: a pure expression does nothing in statement position
• warning: Name … is already introduced in an enclosing scope as value .. in class Test. Did you intend to match it using backquoted …?

For each failed test I made a quick call to either add the diagnostics to the test log, fix the test code to satisfy the new diagnostics or add a condition to refchecks to skip the check. If this were to go forward, polishing would require revisiting the decisions.

Open question:

• Are some of the new diagnostics prone to false positives in the light of type errors? Nothing immediately stuck out in the partests.

• What would be the best way to deal with the new edge cases handled in RefChecks that make this possible?

  Some thoughts:

  Most of these typerReportedErrors conditions prevent assertion failures or null pointer exceptions. The current conditionals I put there are actually rejecting more cases than necessary.

  More precise would be checking for the exact conditions, e.g. something being null.

  An alternative more wholesale approach would be simply catch and ignore any exception that actually occurs in this best effort mode of refchecks. This might make the mode more resilient against crashes in potential gaps in partest coverage. But it might be too blunt of an instrument even when only used in this best-effort mode.