Survive TypeErrors in isMatchedBy

[odersky]

Fixes #15673

[odersky]

How I fixed it:

At first, I was a bit puzzled why a change to hasKnownMembers would have an effect like the one seen in #15673. The test case was really simple, so that was a plus. I compiled with -Xprompt and looked at the stack trace. That indicated that the error was a TypeError that was raised somewhere else and that was caught and issued in typedUnadapted. I grepped for the error message and found the method where it was issued: TypeRef#argDenot. I converted the TypeError to AssertionError to see the stack trace where it was issued: isMatchedBy in ProtoTypes. That explained why it would appear now as a regression: hasUnknownMembers overapproximates less in #14762, so the failing code path after the hasUnknownMembers in isMatchedBy is now taken where previously it was masked.

The question was still how to fix it. The problem was as explained in the new comment in hasmatchingMember

          // We have a type `CC[A]#C` where `CC`'s upper bound is `[X] => Any`, but
          // the current constraint stipulates CC <: SeqOps[...], where `SeqOps` defines
          // the `C` parameter. We try to resolve this using `argDenot` but `argDenot`
          // consults the base type of `CC`, which is not `SeqOps`, so it does not
          // find a corresponding argument. In fact, `argDenot` is not allowed to
          // consult short-lived things like the current constraint, so it has no other
          // choice. The problem will be healed later, when normal selection fails
          // and we try to instantiate type variables to compensate. But we have to make
          // sure we do not issue a type error before we get there.

The fix then was simply to catch a TypeError in isMatchedBy and return false instead. That would catch other TypeErrors as well (e.g. CyclicReference). Arguably that's OK. isMatchedBy is a low-level operation that should not itself issue errors and should fail in a safe way when it encounters a TypeError.

some more output to that message to see the current

[odersky]

The CB build fails because of this:

sbt.librarymanagement.ResolveException: Error downloading tools.jackson:jackson-base:3.0.0-SNAPSHOT
[error]   Not found
[error]   Not found
[error]   not found: /root/.ivy2/local/tools.jackson/jackson-base/3.0.0-SNAPSHOT/ivys/ivy.xml
[error]   not found: https://scala-webapps.epfl.ch/artifactory/sbt-plugin-releases/tools.jackson/jackson-base/3.0.0-SNAPSHOT/ivys/ivy.xml
[error]   download error: Caught java.io.IOException (Server returned HTTP response code: 409 for URL: https://scala-webapps.epfl.ch/artifactory/central/tools/jackson/jackson-base/3.0.0-SNAPSHOT/jackson-base-3.0.0-SNAPSHOT.pom) while downloading https://scala-webapps.epfl.ch/artifactory/central/tools/jackson/jackson-base/3.0.0-SNAPSHOT/jackson-base-3.0.0-SNAPSHOT.pom
[error]   not found: https://oss.sonatype.org/content/repositories/snapshots/tools/jackson/jackson-base/3.0.0-SNAPSHOT/jackson-base-3.0.0-SNAPSHOT.pom

[dwijnand]

Now there's a real puzzler: how does catching a TypeError cause scala-webapps.epfl.ch to start returning 409s?! 😄

[dwijnand]

This seems like a little extreme. Is there no way to add a guard somewhere that quietly returns false instead of recovering from a thrown exception? Or can we at least tighten around what call can't be guarded but we want to recover from it throwing?

[odersky]

We recover from TypeError in several other places as well, so this is nothing new.

[dwijnand]

Ah, I see, 24 matched lines of with "case" and "TypeError". OK, fair enough.

[griggt]

Rebased to fix community build failure.

[griggt]

Thanks for the explanation, I was struggling to make the connection.