}
  }

  /*
   * For a discussion of the signature of verifyNotNull, see the discussion above
   * Preconditions.checkNotNull.
   *
   * (verifyNotNull has many fewer "problem" callers, so we could try to be stricter. On the other
   * hand, verifyNotNull arguably has more reason to accept nullable arguments in the first
   * place....)
   */

  /**

      boolean expression,
      /*
       * TODO(cpovirk): Consider removing @CheckForNull here, as we've done with the other methods'
       * errorMessageTemplate parameters: It is unlikely that callers intend for their string
       * template to be null (though we do handle that case gracefully at runtime). I've left this
       * one as it is because one of our users has defined a wrapper API around Preconditions,

    @Override
    public String toString() {
      return className;
    }
  }

  /**
   * Returns all locations that {@code classloader} and parent loaders load classes and resources
   * from. Callers can {@linkplain LocationInfo#scanResources scan} individual locations selectively
   * or even in parallel.
   */
  static ImmutableSet<LocationInfo> locationsFrom(ClassLoader classloader) {

   * loading the value for this key, simply waits for that thread to finish and returns its loaded
   * value. Note that multiple threads can concurrently load values for distinct keys.
   *
   * <p>This method does not alter the state of this {@code CacheBuilder} instance, so it can be
   * invoked again to create multiple independent caches.
   *
   * @param loader the cache loader used to obtain new values

    }

    @Override
    public boolean matches(char c) {
      return predicate.apply(c);
    }

    @SuppressWarnings("deprecation") // intentional; deprecation is for callers primarily
    @Override
    public boolean apply(Character character) {
      return predicate.apply(checkNotNull(character));
    }

    @Override
    public String toString() {

    // except TypeVariable.
    return of(new TypeResolver().resolveType(runtimeType));
  }

  /**
   * Ensures that this type token doesn't contain type variables, which can cause unchecked type
   * errors for callers like {@link TypeToInstanceMap}.
   */
  @CanIgnoreReturnValue
  final TypeToken<T> rejectTypeVariables() {
    new TypeVisitor() {
      @Override
      void visitTypeVariable(TypeVariable<?> type) {

 * supertype of `Function<A, B>` turns out to be massively more useful to callers in practice: They
 * want their output to be non-null in operations like `stream.map(myConverter)`, and we can
 * guarantee that as long as we also require the input type to be non-null[*] (which is a
 * requirement that existing callers already fulfill).
 *
 * Disclaimer: Part of the reason that callers are so well adapted to `Function<A, B>` may be that

    return incidentEdges();
  }

  @Override
  public Set<E> outEdges() {
    return incidentEdges();
  }

  @Override
  public N adjacentNode(E edge) {
    // We're relying on callers to call this method only with an edge that's in the graph.
    return requireNonNull(incidentEdgeMap.get(edge));
  }

  @Override
  @CheckForNull
  public N removeInEdge(E edge, boolean isSelfLoop) {

  }

  /**
   * A sensible, albeit inefficient, definition of {@link #size} in terms of {@link #entrySet}. If
   * you override {@link #entrySet}, you may wish to override {@link #size} to forward to this
   * implementation.
   *
   * @since 7.0
   */
  protected int standardSize() {
    return Multisets.linearTimeSizeImpl(this);
  }

  /**

 * {@link ImmutableList}) instead of the general collection interface type (such as {@link List}).
 * This communicates to your callers all of the semantic guarantees listed above, which is almost
 * always very useful information.
 *
 * <p>On the other hand, a <i>parameter</i> type of {@link ImmutableList} is generally a nuisance to
 * callers. Instead, accept {@link Iterable} and have your method or constructor body pass it to the