Issue warnings instead of errors

1. Warnings are more consistent with exhaustivity check where only
warnings are issued
2. Errors are not friendly for prototyping, where the programmer makes
assumptions about what values are possible.

Author: liufengyun

compiler/src/dotty/tools/dotc/typer/Checking.scala

@@ -684,7 +684,7 @@ trait Checking {
       val problem = if (pat.tpe <:< reportedPt) "is more specialized than" else "does not match"
       val fix = if (isPatDef) "adding `: @unchecked` after the expression" else "writing `case ` before the full pattern"
       val pos = if (isPatDef) sel.srcPos else pat.srcPos
-      report.errorOrMigrationWarning(
+      report.warning(
         ex"""pattern's type ${pat.tpe} $problem the right hand side expression's type $reportedPt
             |
             |If the narrowing is intentional, this can be communicated by $fix.${err.rewriteNotice}""",

compiler/test/dotty/tools/dotc/CompilationTests.scala

@@ -118,7 +118,7 @@ class CompilationTests {
     aggregateTests(
       compileFilesInDir("tests/neg", defaultOptions),
       compileFilesInDir("tests/neg-tailcall", defaultOptions),
-      compileFilesInDir("tests/neg-strict", defaultOptions.and("-source", "3.1")),
+      compileFilesInDir("tests/neg-strict", defaultOptions.and("-source", "3.1", "-Xfatal-warnings")),
       compileFilesInDir("tests/neg-no-kind-polymorphism", defaultOptions and "-Yno-kind-polymorphism"),
       compileFilesInDir("tests/neg-custom-args/deprecation", defaultOptions.and("-Xfatal-warnings", "-deprecation")),
       compileFilesInDir("tests/neg-custom-args/fatal-warnings", defaultOptions.and("-Xfatal-warnings")),

docs/docs/reference/changed-features/pattern-bindings.md

@@ -6,7 +6,7 @@ title: "Pattern Bindings"
 In Scala 2, pattern bindings in `val` definitions and `for` expressions are
 loosely typed. Potentially failing matches are still accepted at compile-time,
 but may influence the program's runtime behavior.
-From Scala 3.1 on, type checking rules will be tightened so that errors are reported at compile-time instead.
+From Scala 3.1 on, type checking rules will be tightened so that warnings are reported at compile-time instead.
 
 ## Bindings in Pattern Definitions
 
@@ -15,7 +15,7 @@ val xs: List[Any] = List(1, 2, 3)
 val (x: String) :: _ = xs   // error: pattern's type String is more specialized
                             // than the right hand side expression's type Any
 ```
-This code gives a compile-time error in Scala 3.1 (and also in Scala 3.0 under the `-source 3.1` setting) whereas it will fail at runtime with a `ClassCastException` in Scala 2. In Scala 3.1, a pattern binding is only allowed if the pattern is _irrefutable_, that is, if the right-hand side's type conforms to the pattern's type. For instance, the following is OK:
+This code gives a compile-time warning in Scala 3.1 (and also in Scala 3.0 under the `-source 3.1` setting) whereas it will fail at runtime with a `ClassCastException` in Scala 2. In Scala 3.1, a pattern binding is only allowed if the pattern is _irrefutable_, that is, if the right-hand side's type conforms to the pattern's type. For instance, the following is OK:
 ```scala
   val pair = (1, true)
   val (x, y) = pair
@@ -25,7 +25,7 @@ want to decompose it like this:
 ```scala
 val first :: rest = elems   // error
 ```
-This works in Scala 2. In fact it is a typical use case for Scala 2's rules. But in Scala 3.1 it will give a type error. One can avoid the error by marking the right-hand side with an `@unchecked` annotation:
+This works in Scala 2. In fact it is a typical use case for Scala 2's rules. But in Scala 3.1 it will give a warning. One can avoid the warning by marking the right-hand side with an `@unchecked` annotation:
 ```scala
 val first :: rest = elems: @unchecked   // OK
 ```
@@ -40,7 +40,7 @@ val elems: List[Any] = List((1, 2), "hello", (3, 4))
 for ((x, y) <- elems) yield (y, x) // error: pattern's type (Any, Any) is more specialized
                                    // than the right hand side expression's type Any
 ```
-This code gives a compile-time error in Scala 3.1 whereas in Scala 2 the list `elems`
+This code gives a compile-time warning in Scala 3.1 whereas in Scala 2 the list `elems`
 is filtered to retain only the elements of tuple type that match the pattern `(x, y)`.
 The filtering functionality can be obtained in Scala 3 by prefixing the pattern with `case`:
 ```scala