* - columnIterator.remove() succeeded, so it must have returned a value, so it must have been
       * initialized by next() -- which initializes rowEntry, too.
       *
       * - rowEntry isn't cleared except below. If it was cleared below, then either
       *   columnIterator.remove() would have failed above (if the user hasn't called next() since
       *   then) or rowEntry would have been initialized by next() (as discussed above).
       */

        }

        // All nonces should be unique (high entropy from SecureRandom)
        assertEquals(sampleSize, uniqueCounters.size(), "All nonces should have unique values");

        // Verify that nonces have good entropy (not predictable)
        // With SecureRandom + counter XOR, they should all be different
        Set<String> uniqueNonces = new HashSet<>();
        for (byte[] nonce : nonces) {

		issFromToken, _ = v.(string)
	}

	// Since issFromToken can have `/` characters (it is typically the
	// provider URL), we hash and encode it to base64 here. This is needed
	// because there will be a policy mapping stored on drives whose
	// filename is this parentUser: therefore, it needs to have only valid
	// filename characters and needs to have bounded length.
	{
		h := sha256.New()

# proto-file: devtools/build_cleaner/proto/actions.proto
# proto-message: ActionSpecs

# Python rules should not have more than one source file.
action_spec {
  action: CHECK_FILE_COUNT
  file_count_params {
    rule_selector {
      rule_kind_regex: "^.*py(type)?(_strict)?_(binary|library|test).*$"
      generator_function_regex: "^(?!boq_header)$"
    }
    max_source_count: 1
  }

 *       String}.
 *   <li>{@code getElement} on a {@code Multiset.Entry<@Nullable String>} returns {@code @Nullable
 *       String}.
 * </ul>
 *
 * This is the same behavior as type-variable usages have to Kotlin and to the Checker Framework.
 * Contrast the method above to:
 *
 * <ul>
 *   <li>methods whose return type is a type variable but which can never return {@code null},

 *       String}.
 *   <li>{@code getElement} on a {@code Multiset.Entry<@Nullable String>} returns {@code @Nullable
 *       String}.
 * </ul>
 *
 * This is the same behavior as type-variable usages have to Kotlin and to the Checker Framework.
 * Contrast the method above to:
 *
 * <ul>
 *   <li>methods whose return type is a type variable but which can never return {@code null},

 *       String}.
 *   <li>{@code getElement} on a {@code Multiset.Entry<@Nullable String>} returns {@code @Nullable
 *       String}.
 * </ul>
 *
 * This is the same behavior as type-variable usages have to Kotlin and to the Checker Framework.
 * Contrast the method above to:
 *
 * <ul>
 *   <li>methods whose return type is a type variable but which can never return {@code null},

 *       String}.
 *   <li>{@code getElement} on a {@code Multiset.Entry<@Nullable String>} returns {@code @Nullable
 *       String}.
 * </ul>
 *
 * This is the same behavior as type-variable usages have to Kotlin and to the Checker Framework.
 * Contrast the method above to:
 *
 * <ul>
 *   <li>methods whose return type is a type variable but which can never return {@code null},

 *       String}.
 *   <li>{@code getElement} on a {@code Multiset.Entry<@Nullable String>} returns {@code @Nullable
 *       String}.
 * </ul>
 *
 * This is the same behavior as type-variable usages have to Kotlin and to the Checker Framework.
 * Contrast the method above to:
 *
 * <ul>
 *   <li>methods whose return type is a type variable but which can never return {@code null},

 * second invocation, so implementors have made various choices, including:
 *
 * <ul>
 *   <li>returning the same iterator again
 *   <li>throwing an exception of some kind
 *   <li>or the usual, <i>robust</i> behavior, which all known {@link Collection} implementations
 *       have, of returning a new, independent iterator
 * </ul>
 *