* iterator} method only once, and should be tested using this class. Exceptions to this rule should
 * be clearly documented.
 *
 * <p>Note that although your APIs should be liberal in what they accept, your methods which
 * <i>return</i> iterables should make every attempt to return ones of the robust variety.
 *
 * <p>This testing utility is not thread-safe.
 *
 * @author Kevin Bourrillion

  }

  /**
   * Returns the {@link Method} instance for {@link #testAddAll_unsupportedNonePresent()} so that
   * tests can suppress it with {@code FeatureSpecificTestSuiteBuilder.suppressing()} while we
   * figure out what to do with <a href="http://goo.gl/qJBruX">{@code ConcurrentHashMap} support for
   * {@code entrySet().add()}</a>.
   */
  @J2ktIncompatible

        But Guava aims to provide functionality that is useful across boundaries of projects,
        companies, or even industries — utilities useful for a sizable proportion of all Java
        programmers everywhere. If you can give enough detail such that any of us can imagine coming
        across a similar need in our own work, that's extremely helpful in studying how broadly
        useful the proposed change will be.

  - type: textarea

   *
   * <p>The {@code AbstractListTester} implementation overrides {@link
   * AbstractCollectionTester#expectContents(Collection)} to verify that the order of the elements
   * in the list under test matches what is expected.
   */
  @Override
  protected void expectContents(Collection<E> expectedCollection) {
    List<E> expectedList = Helpers.copyToList(expectedCollection);

  - type: textarea
    attributes:
      label: 1. What are you trying to do?
    validations:
      required: true

  - type: textarea
    attributes:
      label: 2. What's the best code you can write to accomplish that without the new feature?
    validations:
      required: true

  - type: textarea
    attributes:
      label: 3. What would that same code look like if we added your feature?
    validations:

start by opening a new issue describing the bug or feature you're intending to
fix. Even if you think it's relatively minor, it's helpful to know what people
are working on. And as mentioned above, API changes should be discussed
thoroughly before moving to code.

Some examples of types of pull requests that are immediately helpful:

  - Fixing a bug without changing a public API.
  - Fixing or improving documentation.

  }

  @Override
  public <T> T[] toArray(T[] a) {
    return delegate.toArray(a);
  }

  @CanIgnoreReturnValue
  private <T> T checkValid(T t) {
    // a ClassCastException is what's supposed to happen!
    @SuppressWarnings("unchecked")
    E e = (E) t;
    int unused = comparator().compare(e, e);
    return t;
  }

  @Override
  public boolean equals(@Nullable Object obj) {

     * extra state from AbstractFuture), our options are limited: A call to setException() would be
     * a no-op. We could log, but if that's what we really want, we should modify
     * AbstractFuture.executeListener to do so, since that method would have the ability to continue
     * to execute other listeners.
     *

        assertWithMessage("roundToDouble(" + input + ", " + mode + ")")
            .that(BigIntegerMath.roundToDouble(input, mode))
            .isEqualTo(expectation);
      }

      if (!expectedValues.containsKey(UNNECESSARY)) {
        assertWithMessage("Expected roundUnnecessaryShouldThrow call")
            .that(unnecessaryShouldThrow)
            .isTrue();
        try {

        assertWithMessage("roundToDouble(" + input + ", " + mode + ")")
            .that(BigIntegerMath.roundToDouble(input, mode))
            .isEqualTo(expectation);
      }

      if (!expectedValues.containsKey(UNNECESSARY)) {
        assertWithMessage("Expected roundUnnecessaryShouldThrow call")
            .that(unnecessaryShouldThrow)
            .isTrue();
        try {