// RUN: %target-typecheck-verify-swift

enum Hey {
  case listen
}

func test() {
  switch Hey.listen {
  case nil: // expected-warning {{type 'Hey' is not optional, value can never be nil}}
    break
  default:
    break
  }
}

struct Nilable: ExpressibleByNilLiteral {
  init(nilLiteral: ()) {}
}

func testNil() {
  // N.B. A deeply confusing case as no conversion is performed on the `nil`
  // literal. Instead, the match subject is converted to `Nilable?` and compared
  // using ~=.
  switch Nilable(nilLiteral: ()) {
  case nil: // expected-warning {{type 'Nilable' is not optional, value can never be nil}}
    break
  default:
    break
  }
}

// RUN: %target-typecheck-verify-swift

enum Hey {
  case listen
}

func test() {
  switch Hey.listen {
  case nil: // expected-warning {{type 'Hey' is not optional, value can never be nil}}
    break
  default:
    break
  }
}

--- 
+++ 
@@ -12,3 +12,19 @@
     break
   }
 }
+
+struct Nilable: ExpressibleByNilLiteral {
+  init(nilLiteral: ()) {}
+}
+
+func testNil() {
+  // N.B. A deeply confusing case as no conversion is performed on the `nil`
+  // literal. Instead, the match subject is converted to `Nilable?` and compared
+  // using ~=.
+  switch Nilable(nilLiteral: ()) {
+  case nil: // expected-warning {{type 'Nilable' is not optional, value can never be nil}}
+    break
+  default:
+    break
+  }
+}
Augment Test for Confusing ExpressibleByNilLiteral Case

Add a test for an extremely confusing behavior of switches for
ExpressibleByNilLiteral-conforming types. From the looks of the expression
tree, one would hope that `case nil` would match such types. Instead, the
subject value is up-converted to an optional and compared to `nil` directly
with ~=.
