Fix #5067: handle scrutinee of bottom type in pattern matcher

[abeln]

When desugaring pattern matching code for expressions where the
matched value has type Null or Nothing, we used to generate code
that's type-incorrect.

Example:

val Some(x) = null

got desugared into

val x: Nothing =
      matchResult1[Nothing]:
        {
          case val x1: Null @unchecked = null: Null @unchecked
          if x1.ne(null) then
            {
              case val x: Nothing = x1.value.asInstanceOf[Nothing]
              return[matchResult1] x: Nothing
            }
           else ()
          return[matchResult1] throw new MatchError(x1)
        }

There were two problems here:

1. x1.ne(null)
2. x1.value

In both cases, we're trying to invoke methods that don't exist for type
Nothing (and #2 doesn't exist for Null).

This commits changes the desugaring so that

1. is solved by adding an ascription, if needed: (x1: AnyRef).ne(null)
2. is added by generating throw-away but type-correct code that never
   executes: throw null

[odersky]

Adding a new kind of plan to the pattern matcher is a fairly big change/complication. To do this "just" to make the compiler not crash for a non-sensical case might go too far. I have a tendency to do what scalac does and disallow these patterns.

[odersky]

@abeln Can you change the PR to outlaw these situations instead? Thanks!

[sjrd]

Here is another suggestion that does not require another plan:

• Keep generating the TestPlan(NonNullTest, ...), but in the onSuccess use a ResultPlan(tpd.Throw(tpd.Null())), with a comment explaining that this is dead code anyway.
• In testNonNull, insert an ascription (_: AnyRef) before calling eq if the receiver's type is Null or Nothing.

[odersky]

@sjrd I like that approach. @abeln Are you happy to continue the implementation?

[abeln]

@odersky yes, I'll take a look. Got busy preparing the proposal for explicit nulls!

[abeln]

@odersky PTAL
Implemented the approach suggested by @sjrd and added the test suggested by @Blaisorblade

[odersky]

My main concern is the duplication in isSubtypeOfBottom.

[abeln]

@odersky PTAL

[odersky]

@abeln Looks good now.