//      since, after all, this class is also a reentrant mutual exclusion lock!?

  /*
   * One of the key challenges of this class is to prevent lost signals, while trying hard to
   * minimize unnecessary signals. One simple and correct algorithm is to signal some other waiter
   * with a satisfied guard (if one exists) whenever any thread occupying the monitor exits the

    sizesToTest.retainAll(features);
    features.removeAll(sizesToTest);

    addImpliedFeatures(sizesToTest);
    sizesToTest.retainAll(asList(CollectionSize.ZERO, CollectionSize.ONE, CollectionSize.SEVERAL));

    logger.fine("   Sizes: " + formatFeatureSet(sizesToTest));

    if (sizesToTest.isEmpty()) {
      throw new IllegalStateException(
          name

 *       suite()} method with {@code Suppress}. Would {@code FooTest} itself be suppressed, too?
 *   <li>In at least one case, a use of {@code sun.misc.FpUtils}, the test will not even
 *       <i>compile</i> against Android. Now, this might be an artifact of our build system, one
 *       that we could probably work around. Or we could manually strip the test from open-source

    for (ClassInfo info : ClassPath.from(getClass().getClassLoader()).getAllClasses()) {
      if (!GUAVA_PACKAGES.contains(info.getPackageName())) {
        continue;
      }
      if (
      /*
       * At least one of the classes nested inside TypeResolverTest triggers a bug under older JDKs:
       * https://bugs.openjdk.org/browse/JDK-8215328 -> https://bugs.openjdk.org/browse/JDK-8215470

   *
   * @return {@code true} if the graph was modified as a result of this call
   */
  @CanIgnoreReturnValue
  boolean addNode(N node);

  /**
   * Adds an edge connecting {@code nodeU} to {@code nodeV} if one is not already present.
   *
   * <p>If the graph is directed, the resultant edge will be directed; otherwise, it will be
   * undirected.
   *

    validations:
      required: false

  - type: checkboxes
    id: related-idea
    attributes:
      label: "Related Idea"
      options:
        - label: "Has this idea, or one like it, been proposed before?"
        - label: "Does this affect error handling?"
        - label: "Is this about generics?"

          #Comma separated list of labels that can be assigned to PRs to exclude them from being marked as stale
          exempt-pr-labels: "override-stale"
          #Limit the No. of API calls in one run default value is 30.
          operations-per-run: 1000
          days-before-issue-stale: 7
          days-before-issue-close: 7
          stale-issue-label: "stale"

#### Operation { #operation }

"Operation" here refers to one of the HTTP "methods".

One of:

* `POST`
* `GET`
* `PUT`
* `DELETE`

...and the more exotic ones:

* `OPTIONS`
* `HEAD`
* `PATCH`
* `TRACE`

In the HTTP protocol, you can communicate to each path using one (or more) of these "methods".

---

    int initialSize = collection.size();
    assertTrue("remove(present) should return true", collection.remove(e0()));
    assertEquals(
        "remove(present) should decrease a collection's size by one.",
        initialSize - 1,
        collection.size());
    expectMissing(e0());
  }

  @CollectionFeature.Require({SUPPORTS_REMOVE, FAILS_FAST_ON_CONCURRENT_MODIFICATION})
  @CollectionSize.Require(SEVERAL)

carefully. Because of this, if you're interested in seeing a new feature in
Guava, the best approach is to create an [issue][] (or comment on an existing
issue if there is one) requesting the feature and describing specific use cases
for it.

If the feature has merit, it will go through a thorough process of API design
and review. Any code should come after this.