Reword comment about the current implementation of ^.

--
PiperOrigin-RevId: 148488719
MOS_MIGRATED_REVID=148488719

1 files changed, 6 insertions, 3 deletions

diff --git a/src/main/java/com/google/devtools/build/lib/query2/engine/BinaryOperatorExpression.java b/src/main/java/com/google/devtools/build/lib/query2/engine/BinaryOperatorExpression.java
index f2823be237..89374d0a94 100644
--- a/src/main/java/com/google/devtools/build/lib/query2/engine/BinaryOperatorExpression.java
+++ b/src/main/java/com/google/devtools/build/lib/query2/engine/BinaryOperatorExpression.java
@@ -90,10 +90,13 @@ public class BinaryOperatorExpression extends QueryExpression {
       return;
     }
 
-    // Intersection is not associative, so we are forced to pin both the left-hand and right-hand
-    // side of the operation at the same time.
+    // For each right-hand side operand, intersection cannot be performed in a streaming manner; the
+    // entire result of that operand is needed. So, in order to avoid pinning too much in memory at
+    // once, we process each right-hand side operand one at a time and throw away that operand's
+    // result.
     // TODO(bazel-team): Consider keeping just the name / label of the right-hand side results
-    // instead of the potentially heavy-weight instances of type T.
+    // instead of the potentially heavy-weight instances of type T. This would let us process all
+    // right-hand side operands in parallel without worrying about memory usage.
     Preconditions.checkState(operator == TokenKind.INTERSECT || operator == TokenKind.CARET,
         operator);
     for (int i = 1; i < operands.size(); i++) {