}, {
  "scenario" : "org.gradle.performance.regression.corefeature.ExcludeRuleMergingPerformanceTest.merge exclude rules",
  "durations" : [ {
    "testProject" : "excludeRuleMergingBuild",
    "linux" : 290
  } ]
}, {
  "scenario" : "org.gradle.performance.regression.corefeature.ExcludeRuleMergingPerformanceTest.merge exclude rules (parallel)",
  "durations" : [ {
    "testProject" : "excludeRuleMergingBuild",
    "linux" : 238
  } ]

                  <project path="$PROJECT_DIR$/build-logic-commons/build-platform" />
                  <project path="$PROJECT_DIR$/build-logic-commons/code-quality-rules" />
                  <project path="$PROJECT_DIR$/build-logic-commons/gradle-plugin" />
                  <project path="$PROJECT_DIR$/build-logic-commons/module-identity" />

## GitHub docs: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners
##
## CODEOWNERS style rules:
## 1. Prefer team ownership over individual user ownership.
## 2. GBT-related team should be listed first.
## 3. Try to keep paths alphabetically sorted within visual groups.
## 4. List individual owners last.
##

# Build infrastructure

      if (array[i] == target) {
        return i;
      }
    }
    return -1;
  }

  /**
   * Returns the least value present in {@code array}, using the same rules of comparison as {@link
   * Math#min(float, float)}.
   *
   * @param array a <i>nonempty</i> array of {@code float} values
   * @return the value present in {@code array} that is less than or equal to every other value in

    define_values = {"tflite_converter": "true"},
    visibility = ["//visibility:public"],
)

# DO NOT ADD ANY NEW EXCEPTIONS TO THIS LIST!
# Instead, please use public APIs or public build rules TF provides.
# If you need functionality that is not exposed, we will work with you to expand our public APIs.
# TODO(b/173549186): Move Google-internal TF code out of learning/brain
package_group(
    name = "internal",

<h3 id="Type_unification_rules">Type unification rules</h3>

<p>
The type unification rules describe if and how two types unify.
The precise details are relevant for Go implementations,
affect the specifics of error messages (such as whether
a compiler reports a type inference or other error),
and may explain why type inference fails in unusual code situations.
But by and large these rules can be ignored when writing Go code:

      if (array[i] == target) {
        return i;
      }
    }
    return -1;
  }

  /**
   * Returns the least value present in {@code array}, using the same rules of comparison as {@link
   * Math#min(double, double)}.
   *
   * @param array a <i>nonempty</i> array of {@code double} values
   * @return the value present in {@code array} that is less than or equal to every other value in

   * {@code C}
   *
   * <ul>
   *   <li>All visible static methods are checked such that passing null for any parameter that's
   *       not annotated nullable (according to the rules of {@link NullPointerTester}) should throw
   *       {@link NullPointerException}.
   *   <li>If there is any visible constructor or visible static factory method declared by the

import java.util.concurrent.TimeUnit;
import org.jspecify.annotations.NullUnmarked;
import org.jspecify.annotations.Nullable;

/**
 * An unbounded {@linkplain BlockingQueue blocking queue} that uses the same ordering rules as class
 * {@link PriorityQueue} and supplies blocking retrieval operations. While this queue is logically
 * unbounded, attempted additions may fail due to resource exhaustion (causing {@code

The commit messages that accompany your code changes are an important piece of documentation. Please follow these guidelines when creating commits:

* [Write good commit messages.](https://cbea.ms/git-commit/#seven-rules)