* 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
   * {@code requireNonNull}: Our use case is the one in which {@code T} has parametric nullness—and
   * thus its value may be legitimately {@code null}.)
   */
  @ParametricNullness

   * 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
   * {@code requireNonNull}: Our use case is the one in which {@code T} has parametric nullness—and
   * thus its value may be legitimately {@code null}.)
   */
  @ParametricNullness

    for (QuantilesAlgorithm algorithm : NON_REFERENCE_ALGORITHMS) {
      Map<Integer, Double> quantiles = algorithm.multipleQuantiles(indexes, 100, dataset.clone());
      assertWithMessage("Wrong keys from %s", algorithm)
          .that(quantiles.keySet())
          .isEqualTo(indexes);
      for (int i : indexes) {
        assertWithMessage("Mismatch between %s and %s at %s", algorithm, REFERENCE_ALGORITHM, i)

	for _, cat := range testcats {
		for _, test := range cat.tests {
			parser.allowABI = cat.allowABI
			parser.errorCount = 0
			parser.lineNum++
			if !parser.pseudo(test.pseudo, tokenize(test.operands)) {
				t.Fatalf("Wrong pseudo-instruction: %s", test.pseudo)
			}
			errorLine := buf.String()
			if test.expected != errorLine {
				t.Errorf("Unexpected error %q; expected %q", errorLine, test.expected)
			}
			buf.Reset()
		}
	}

For any non-trivial change, we need to be able to answer these questions:

* Why is this change done? What's the use case?
* For user-facing features, what will the API look like?
* What test cases should it have? What could go wrong?
* How will it roughly be implemented? We'll happily provide code pointers to save you time.

We may ask you to answer these questions directly in the GitHub issue or (for large changes) in a shared Google Doc.

    * An example is `404`, for a "Not Found" response.
    * For generic errors from the client, you can just use `400`.
* `500 - 599` are for server errors. You almost never use them directly. When something goes wrong at some part in your application code, or server, it will automatically return one of these status codes.

/// tip

   * 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
   * {@code requireNonNull}: Our use case is the one in which {@code T} has parametric nullness—and
   * thus its value may be legitimately {@code null}.)
   */
  @ParametricNullness

   * 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
   * {@code requireNonNull}: Our use case is the one in which {@code T} has parametric nullness—and
   * thus its value may be legitimately {@code null}.)
   */
  @ParametricNullness

#    // missing class!
#    'com.missing.dependency.WTF',
#    // ...
#   ]
#
# Wildcards are not allowed, excludes must be exact. The build also fails with
# the message "Invalid exclusions, nothing is wrong with these classes" if
# extraneous classes are in the excludes list, this ensures the list is
# up-to-date, and that each module accurately documents the evil things
# that its dependencies do.
#

 * instead.
 *
 * {@snippet :
 * // Do NOT do this
 * Splitter splitter = Splitter.on('/');
 * splitter.trimResults(); // does nothing!
 * return splitter.split("wrong / wrong / wrong");
 * }
 *
 * <p>For separator-based splitters that do not use {@code omitEmptyStrings}, an input string
 * containing {@code n} occurrences of the separator naturally yields an iterable of size {@code n +