Remove obsolete code in the verifier.

We now handle verification errors depending on their kind after the
method has been verified.

Test: test.py
Bug: 176960283
Change-Id: Ib1c5fde157d516907f176e16fda00fe05ac25ff1
diff --git a/runtime/verifier/method_verifier.cc b/runtime/verifier/method_verifier.cc
index 9c6798d..017846b 100644
--- a/runtime/verifier/method_verifier.cc
+++ b/runtime/verifier/method_verifier.cc
@@ -5538,27 +5538,6 @@
       case VERIFY_ERROR_ACCESS_METHOD:
       case VERIFY_ERROR_INSTANTIATION:
       case VERIFY_ERROR_CLASS_CHANGE:
-      case VERIFY_ERROR_FORCE_INTERPRETER:
-      case VERIFY_ERROR_LOCKING:
-        if (IsAotMode() || !can_load_classes_) {
-          if (error != VERIFY_ERROR_ACCESS_CLASS &&
-              error != VERIFY_ERROR_ACCESS_FIELD &&
-              error != VERIFY_ERROR_NO_METHOD &&
-              error != VERIFY_ERROR_ACCESS_METHOD) {
-            // If we're optimistically running verification at compile time, turn NO_xxx,
-            // class change and instantiation errors into soft verification errors so that we
-            // re-verify at runtime. We may fail to find or to agree on access because of not yet
-            // available class loaders, or class loaders that will differ at runtime. In these
-            // cases, we don't want to affect the soundness of the code being compiled. Instead, the
-            // generated code runs "slow paths" that dynamically perform the verification and cause
-            // the behavior to be that akin to an interpreter.
-            error = VERIFY_ERROR_BAD_CLASS_SOFT;
-          }
-        } else {
-          // If we fail again at runtime, mark that this instruction would throw and force this
-          // method to be executed using the interpreter with checks.
-          flags_.have_pending_runtime_throw_failure_ = true;
-        }
         // How to handle runtime failures for instructions that are not flagged kThrow.
         //
         // The verifier may fail before we touch any instruction, for the signature of a method. So
@@ -5581,6 +5560,11 @@
         }
         break;
 
+      case VERIFY_ERROR_FORCE_INTERPRETER:
+      case VERIFY_ERROR_LOCKING:
+        // This will be reported to the runtime as a soft failure.
+        break;
+
         // Indication that verification should be retried at runtime.
       case VERIFY_ERROR_BAD_CLASS_SOFT:
         if (!allow_soft_failures_) {
@@ -5588,8 +5572,8 @@
         }
         break;
 
-        // Hard verification failures at compile time will still fail at runtime, so the class is
-        // marked as rejected to prevent it from being compiled.
+      // Hard verification failures at compile time will still fail at runtime, so the class is
+      // marked as rejected to prevent it from being compiled.
       case VERIFY_ERROR_BAD_CLASS_HARD: {
         flags_.have_pending_hard_failure_ = true;
         break;