}

    /**
     * Setup exactly the same as the above test, except that the child project
     * now depends upon d, which has a transitive dependency on c.  Even though
     * we did list an exclusion on c, it was only from within the context of
     * project b.  We will pick up project c in this case because no
     * restrictions were placed on d.  This demonstrates that a, b, c, & d will
     * all be collected.
     *

      assertThat(afterBurst).isAtLeast(1000);
    }
  }

  /**
   * This neat test shows that no matter what weights we use in our requests, if we push X amount of
   * permits in a cool state, where X = rate * timeToCoolDown, and we have specified a
   * timeToWarmUp() period, it will cost as the prescribed amount of time. E.g., calling
   * [acquire(5), acquire(1)] takes exactly the same time as [acquire(2), acquire(3), acquire(1)].

      assertThat(afterBurst).isAtLeast(1000);
    }
  }

  /**
   * This neat test shows that no matter what weights we use in our requests, if we push X amount of
   * permits in a cool state, where X = rate * timeToCoolDown, and we have specified a
   * timeToWarmUp() period, it will cost as the prescribed amount of time. E.g., calling
   * [acquire(5), acquire(1)] takes exactly the same time as [acquire(2), acquire(3), acquire(1)].

# Security Policy

## Supported Versions

We support the past two Go releases (for example, Go 1.17.x and Go 1.18.x when Go 1.18.x is the latest stable release).

See https://go.dev/wiki/Go-Release-Cycle and in particular the
[Release Maintenance](https://go.dev/wiki/Go-Release-Cycle#release-maintenance)
part of that page.

## Reporting a Vulnerability

<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
    Java package; see

    for (LoadingCache<Object, Object> cache : caches()) {
      cache.getUnchecked(1);
      cache.getUnchecked(2);

      Set<Object> keys = cache.asMap().keySet();
      // We don't know whether these are still in the cache, so we can't assert on the return
      // values of these removes, but the cache should be empty after the removes, regardless.
      keys.remove(1);
      keys.remove(2);

    for (LoadingCache<Object, Object> cache : caches()) {
      cache.getUnchecked(1);
      cache.getUnchecked(2);

      Set<Object> keys = cache.asMap().keySet();
      // We don't know whether these are still in the cache, so we can't assert on the return
      // values of these removes, but the cache should be empty after the removes, regardless.
      keys.remove(1);
      keys.remove(2);

    StringCatcher catcher = new StringCatcher();
    bus.register(catcher);

    // We post the event, but our Executor will not deliver it until instructed.
    bus.post(EVENT);

    List<String> events = catcher.getEvents();
    assertTrue("No events should be delivered synchronously.", events.isEmpty());

    // Now we find the task in our Executor and explicitly activate it.
    List<Runnable> tasks = executor.getTasks();

    }

    deflatedBytes.writeAll(buffer)
    deflatedBytes.writeInt(OCTETS_TO_ADD_BEFORE_INFLATION)

    val totalBytesToRead = inflater.bytesRead + deflatedBytes.size

    // We cannot read all, as the source does not close.
    // Instead, we ensure that all bytes from source have been processed by inflater.
    do {
      inflaterSource.readOrInflate(buffer, Long.MAX_VALUE)

## How the configuration works

We use Kotlin portable DSL to store TeamCity configuration, which means you can easily create a new pipeline
based on a specific branch. Currently, we have two pipelines: `master` and `release`, but you can easily create
and test another isolated pipeline from any branch.