* assume that using setCount() to increase the count is permitted iff add()
   * is permitted and similarly for decrease/remove(). We assume that a
   * setCount() no-op is permitted if either add() or remove() is permitted,
   * though we also allow it to "succeed" if neither is permitted.
   */

  private void assertSetCount(E element, int count) {
    setCountCheckReturnValue(element, count);

   * assume that using setCount() to increase the count is permitted iff add()
   * is permitted and similarly for decrease/remove(). We assume that a
   * setCount() no-op is permitted if either add() or remove() is permitted,
   * though we also allow it to "succeed" if neither is permitted.
   */

  private void assertSetCount(E element, int count) {
    setCountCheckReturnValue(element, count);

     * and will be merged, but overlapping ranges will cause an exception when {@link #build()} is
     * called.
     */
    @CanIgnoreReturnValue
    public Builder<C> addAll(RangeSet<C> ranges) {
      return addAll(ranges.asRanges());
    }

    /**
     * Add all of the specified ranges to this builder. Adjacent ranges are permitted and will be

   *
   * <p>This escaper substitutes {@code 0xFFFD} for non-whitespace control characters and the
   * character values {@code 0xFFFE} and {@code 0xFFFF} which are not permitted in XML. For more
   * detail see section <a href="http://www.w3.org/TR/2008/REC-xml-20081126/#charsets">2.2</a> of
   * the XML specification.
   *

   * with {@code FeatureSpecificTestSuiteBuilder.suppressing()} until <a
   * href="https://bugs.openjdk.org/browse/JDK-6409434">JDK-6409434</a> is fixed. It's unclear
   * whether nulls were to be permitted or forbidden, but presumably the eventual fix will be to
   * permit them, as it seems more likely that code would depend on that behavior than on the other.
   * Thus, we say the bug is in add(), which fails to support null.

   * with {@code FeatureSpecificTestSuiteBuilder.suppressing()} until <a
   * href="https://bugs.openjdk.org/browse/JDK-6409434">JDK-6409434</a> is fixed. It's unclear
   * whether nulls were to be permitted or forbidden, but presumably the eventual fix will be to
   * permit them, as it seems more likely that code would depend on that behavior than on the other.
   * Thus, we say the bug is in add(), which fails to support null.

     * @param cause the cause (which is saved for later retrieval by the {@link #getCause()} method).
     *              (A {@code null} value is permitted, and indicates that the cause is nonexistent or unknown.)
     */
    public CurlException(final String message, final Throwable cause) {
        super(message, cause);
    }

    /**

   * analysis that that means "plain {@code T}" rather than the inferred type {@code @Nullable T}.
   * (And even if annotations on local variables were permitted as an optional hint, no annotation
   * would be the right tool for the job here: {@code @Nullable} is the annotation that we're trying
   * to get rid of, and {@code @NonNull} would be wrong for our use case for the same reason as

   * with {@code FeatureSpecificTestSuiteBuilder.suppressing()} until <a
   * href="https://bugs.openjdk.org/browse/JDK-6409434">JDK-6409434</a> is fixed. It's unclear
   * whether nulls were to be permitted or forbidden, but presumably the eventual fix will be to
   * permit them, as it seems more likely that code would depend on that behavior than on the other.
   * Thus, we say the bug is in set(), which fails to support null.

   * analysis that that means "plain {@code T}" rather than the inferred type {@code @Nullable T}.
   * (And even if annotations on local variables were permitted as an optional hint, no annotation
   * would be the right tool for the job here: {@code @Nullable} is the annotation that we're trying
   * to get rid of, and {@code @NonNull} would be wrong for our use case for the same reason as