From 9595546ff5ca36d480951d4ba7a9118babaa9b63 Mon Sep 17 00:00:00 2001
From: Christopher Lambert <xn137@gmx.de>
Date: Sun, 12 Mar 2023 14:09:37 +0100
Subject: [PATCH] NULL_LITERAL expressions may always be null

there is no reason to give handlers a chance to override this because we
are also not doing this for other literals that we filter out at the
start of the method
---
 nullaway/src/main/java/com/uber/nullaway/NullAway.java | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/nullaway/src/main/java/com/uber/nullaway/NullAway.java b/nullaway/src/main/java/com/uber/nullaway/NullAway.java
index 62d49d2a23..51f63fcd29 100644
--- a/nullaway/src/main/java/com/uber/nullaway/NullAway.java
+++ b/nullaway/src/main/java/com/uber/nullaway/NullAway.java
@@ -2197,14 +2197,14 @@ private boolean mayBeNullExpr(VisitorState state, ExpressionTree expr) {
       // obviously not null
       return false;
     }
+    if (expr.getKind() == Tree.Kind.NULL_LITERAL) {
+      // obviously null, so same as for above literals we return early without consulting handlers
+      return true;
+    }
     // the logic here is to avoid doing dataflow analysis whenever possible
     Symbol exprSymbol = ASTHelpers.getSymbol(expr);
     boolean exprMayBeNull;
     switch (expr.getKind()) {
-      case NULL_LITERAL:
-        // obviously null
-        exprMayBeNull = true;
-        break;
       case ARRAY_ACCESS:
         // unsound!  we cannot check for nullness of array contents yet
         exprMayBeNull = false;