/**
   * Drains the queue as {@linkplain #drain(BlockingQueue, Collection, int, long, TimeUnit)}, but
   * with a different behavior in case it is interrupted while waiting. In that case, the operation
   * will continue as usual, and in the end the thread's interruption status will be set (no {@code
   * InterruptedException} is thrown).
   *
   * @param q the blocking queue to be drained
   * @param buffer where to add the transferred elements

 * autoboxing and varargs array creation may happen as well, even when the verification succeeds and
 * the message ends up unneeded. Performance-sensitive verification checks should continue to use
 * usual form:
 *
 * <pre>{@code
 * Bill bill = remoteService.getLastUnpaidBill();
 * if (bill.status() != Status.UNPAID) {
 *   throw new VerifyException("Unexpected bill status: " + bill.status());
 * }
 * }</pre>
 *

   * expect, but there are some subtleties. First, we do guarantee that, if the output future at
   * index n is done, the output future at index n-1 is also done. (But as usual with futures, some
   * listeners for future n may complete before some for future n-1.) However, it is possible, if
   * one input completes with result X and another later with result Y, for Y to come before X in

<module>
<source path="">
  <!-- Hack to keep collect from hiding collect.testing supersource: -->
  <exclude name="**/testing/**"/>
</source>

<!--
    We used to set this only for packages that had manual supersource. That
    worked everywhere that I know of except for one place: when running the GWT
    util.concurrent tests under Guava.

    The problem is that GWT responds poorly to two .gwt.xml files in the same

<module>
<source path="">
  <!-- Hack to keep collect from hiding collect.testing supersource: -->
  <exclude name="**/testing/**"/>
</source>

<!--
    We used to set this only for packages that had manual supersource. That
    worked everywhere that I know of except for one place: when running the GWT
    util.concurrent tests under Guava.

    The problem is that GWT responds poorly to two .gwt.xml files in the same

<module>
<source path="">
  <!-- Hack to keep collect from hiding collect.testing supersource: -->
  <exclude name="**/testing/**"/>
</source>

<!--
    We used to set this only for packages that had manual supersource. That
    worked everywhere that I know of except for one place: when running the GWT
    util.concurrent tests under Guava.

    The problem is that GWT responds poorly to two .gwt.xml files in the same

    return delegateCollection().comparator();
  }

  // Override indexOf() and lastIndexOf() to be O(log N) instead of O(N).

  @GwtIncompatible // ImmutableSortedSet.indexOf
  // TODO(cpovirk): consider manual binary search under GWT to preserve O(log N) lookup
  @Override
  public int indexOf(@CheckForNull Object target) {
    int index = delegateCollection().indexOf(target);

    } catch (NoSuchElementException expected) {
    }

    try {
      iter.next();
      fail("next() should throw NoSuchElementException as usual");
    } catch (NoSuchElementException expected) {
    }

    try {
      iter.peek();
      fail("peek() should still throw NoSuchElementException after next()");
    } catch (NoSuchElementException expected) {

  abstract long fn(long currentValue, long newValue);

  /**
   * Handles cases of updates involving initialization, resizing, creating new Cells, and/or
   * contention. See above for explanation. This method suffers the usual non-modularity problems of
   * optimistic retry code, relying on rechecked sets of reads.
   *
   * @param x the value
   * @param hc the hash code holder
   * @param wasUncontended false if CAS failed before call

       * We use a runtime check here instead of @AndroidIncompatible: @AndroidIncompatible operates
       * by stripping annotated methods entirely, and if we strip this method, then JUnit would just
       * run the supermethod as usual.
       *
       * TODO: b/292578973: Use @AndroidIncompatible if we change our system to keep the methods in
       * place but to have the test runner skip them. However, note that if we choose to *both*