TensorFlow coding style.

#### General guidelines and philosophy for contribution

*   Include unit tests when you contribute new features, as they help to a)
    prove that your code works correctly, and b) guard against future breaking
    changes to lower the maintenance cost.
*   Bug fixes also generally require unit tests, because the presence of bugs

    // is okay, as stat requests are typically fast, and concurrent requests are
    // often for the same file. Future work can split this up into one lock per
    // key if this proves to be a significant performance bottleneck.
    absl::MutexLock lock(&mu_);
    if (LookupLocked(key, value)) {
      return TF_SetStatus(status, TF_OK, "");
    }
    compute_func(key, value, status);

//     TensorFlow will know to not call these on behalf of users;
//   * increased security as plugins will not be able to alter function table
//     after loading up. Thus, malicious plugins can't alter functionality to
//     probe for gadgets inside core TensorFlow. We can even protect the area
//     of memory where the copies reside to not allow any more writes to it
//     after all copies are created.
template <typename T>

        layers and happens to work before TF 2.4. These will explicitly be
        unsupported now. Converting these ops to Functional API op layers was
        unreliable before TF 2.4, and prone to erroring incomprehensibly or
        being silently buggy.
    *   Code that directly asserts on a Keras symbolic value in cases where ops
        like `tf.rank` used to return a static or symbolic value depending on if

build:resultstore --bes_results_url="https://source.cloud.google.com/results/invocations"
build:resultstore --bes_timeout=600s

# Flag to enable remote config
common --experimental_repo_remote_exec

# Make Bazel not try to probe the host system for a C++ toolchain.
build:rbe_base --config=resultstore
build:rbe_base --repo_env=BAZEL_DO_NOT_DETECT_CPP_TOOLCHAIN=1
build:rbe_base --define=EXECUTOR=remote
build:rbe_base --jobs=800