return Multisets.iteratorImpl(this);
  }

  @Override
  public @Nullable Object[] toArray() {
    return standardToArray();
  }

  @Override
  @SuppressWarnings("nullness") // b/192354773 in our checker affects toArray declarations
  public <T extends @Nullable Object> T[] toArray(T[] array) {
    return standardToArray(array);
  }

  @Override
  public String toString() {
    return entrySet().toString();

            } catch (ClassCastException e) {
              return false;
            }
          }

          @Override
          @SuppressWarnings("nullness") // b/192354773 in our checker affects toArray declarations
          public <T extends @Nullable Object> T[] toArray(T[] array) {
            T[] result = super.toArray(array);
            if (size() < result.length) {

 *       String}.
 *   <li>{@code getElement} on a {@code Multiset.Entry<@Nullable String>} returns {@code @Nullable
 *       String}.
 * </ul>
 *
 * This is the same behavior as type-variable usages have to Kotlin and to the Checker Framework.
 * Contrast the method above to:
 *
 * <ul>
 *   <li>methods whose return type is a type variable but which can never return {@code null},

      @Override
      public @Nullable Object[] toArray() {
        return ObjectArrays.toArrayImpl(this);
      }

      @Override
      @SuppressWarnings("nullness") // b/192354773 in our checker affects toArray declarations
      public <T extends @Nullable Object> T[] toArray(T[] a) {
        return ObjectArrays.toArrayImpl(this, a);
      }

      @Override
      public Spliterator<K> spliterator() {

  @Nullable V getIfCached(@Nullable Object key) {
    Entry<K, V> entry = cacheEntry; // store local reference for thread-safety

    // Check cache. We use == on purpose because it's cheaper and a cache miss is ok.
    if (entry != null && entry.getKey() == key) {
      return entry.getValue();
    }
    return null;
  }

  void clearCache() {
    cacheEntry = null;

        fw.println("#");
        fw.println("# The checker does not handle implicit section names, so they must be explicit and declared as: [[section-name]]");
        fw.println("#");
        fw.println("# The checker also rejects Markdown-style links, such as [text](https://example.com/something) as they do not render properly");

    }

  @CanIgnoreReturnValue
  public final <A extends Appendable> A appendTo(A appendable, @Nullable Object[] parts)
      throws IOException {
    @SuppressWarnings("nullness") // TODO: b/316358623 - Remove suppression after fixing checker
    List<?> partsList = Arrays.<@Nullable Object>asList(parts);
    return appendTo(appendable, partsList);
  }

  /** Appends to {@code appendable} the string representation of each of the remaining arguments. */

}

# Note: this is excluded on the full code base, since any submitted code must
# have passed Google's internal style guidelines.
@test "Check formatting for C++ files" {
    skip "clang-format doesn't match internal clang-format checker"
    echo "clang-format is recommended. Here are the suggested changes:"
    echo "============================="

 *       String}.
 *   <li>{@code getElement} on a {@code Multiset.Entry<@Nullable String>} returns {@code @Nullable
 *       String}.
 * </ul>
 *
 * This is the same behavior as type-variable usages have to Kotlin and to the Checker Framework.
 * Contrast the method above to:
 *
 * <ul>
 *   <li>methods whose return type is a type variable but which can never return {@code null},

 *       String}.
 *   <li>{@code getElement} on a {@code Multiset.Entry<@Nullable String>} returns {@code @Nullable
 *       String}.
 * </ul>
 *
 * This is the same behavior as type-variable usages have to Kotlin and to the Checker Framework.
 * Contrast the method above to:
 *
 * <ul>
 *   <li>methods whose return type is a type variable but which can never return {@code null},