List<E> extremeValues = new ArrayList<>();

      // nulls are usually out of bounds for a subset, so ban them altogether
      for (Object o : elements) {
        if (o == null) {
          throw new NullPointerException();
        }
      }

      // prepare extreme values to be filtered out of view
      E firstExclusive = delegate.belowSamplesGreater();

    super(ImmutableMap.<Object, ImmutableList<Object>>of(), 0);
  }

  /*
   * TODO(b/242884182): Figure out why this helps produce the same class file when we compile most
   * of common.collect a second time with the results of the first compilation on the classpath. Or
   * just back this out once we stop doing that (which we'll do after our internal GWT setup
   * changes).
   */
  @Override

    "@local_config_cuda//cuda:cusolver + "\
    "@local_config_tensorrt//:tensorrt)" --keep_going > $BATS_TEST_TMPDIR/out

  cat <<EOF
There was a path found connecting //tensorflow/tools/pip_package:wheel
to a banned CUDA dependency. Here's the output from bazel query:
EOF
  cat $BATS_TEST_TMPDIR/out
  [[ ! -s $BATS_TEST_TMPDIR/out ]]
}

@test "Pip package doesn't depend on CUDA for static builds (i.e. Windows)" {
  bazel cquery \

      - name: 'Cancel previous runs'
        uses: styfle/cancel-workflow-action@85880fa0301c86cca9da44039ee3bb12d3bedbfa # 0.12.1
        with:
          access_token: ${{ github.token }}
      - name: 'Check out repository'
        uses: actions/checkout@08c6903cd8c0fde910a37f88322edcfb5dd907a8 # v5.0.0
      # When we specify multiple JDKs, the final one becomes the default, which is used to execute Maven itself.

      String originalName = currentThread.getName();
      currentThread.setName("Crawler " + url);
      try {
        fetch(url);
      } catch (IOException e) {
        System.out.printf("XXX: %s %s%n", url, e);
      } finally {
        currentThread.setName(originalName);
      }
    }
  }

  public void fetch(HttpUrl url) throws IOException {

  }

  /** Tests that the {@link Future#get(long, TimeUnit)} method times out correctly. */
  public void testTimeoutOnGetWorksCorrectly() throws InterruptedException, ExecutionException {

    // The task thread waits for the latch, so we expect a timeout here.
    try {
      future.get(20, MILLISECONDS);
      fail("Should have timed out trying to get the value.");
    } catch (TimeoutException expected) {
    } finally {

		[switch_is(level)] DfsEnumInfo e;
	} DfsEnumStruct;

	[op(0x15)]
	int NetrDfsEnumEx([in,string,unique] wchar_t dfs_name,
			[in] uint32_t level,
			[in] uint32_t prefmaxlen,
			[in,out,unique] DfsEnumStruct *info,
			[in,out,unique] uint32_t *totalentries);

      // timed out. e.g. if we weren't event able to grab the lock within the timeout we would never
      // even check the guard. I don't think we care too much about this use case but it could lead
      // to a confusing error message.
      throw new TimeoutException("Timed out waiting for " + this + " to reach the RUNNING state.");
    }
  }

  @Override

    } else {
      events.add(Failure(t, response))
    }
  }

  private fun nextEvent(): Any =
    events.poll(10, TimeUnit.SECONDS)
      ?: throw AssertionError("Timed out waiting for event.")

  fun assertTextMessage(payload: String?) {
    assertThat(nextEvent()).isEqualTo(Message(string = payload))
  }

  fun assertBinaryMessage(payload: ByteString?) {

    streamPrimesToSinkAsynchronously(pipeBody.sink());

    try (Response response = client.newCall(request).execute()) {
      if (!response.isSuccessful()) throw new IOException("Unexpected code " + response);

      System.out.println(response.body().string());
    }
  }

  private void streamPrimesToSinkAsynchronously(final BufferedSink sink) {
    Thread thread = new Thread("writer") {
      @Override public void run() {
        try {