}

	// since we use this container for accounting, we need to ensure its a unified hierarchy.
	if cpu != memory {
		return "", fmt.Errorf("cpu and memory cgroup hierarchy not unified.  cpu: %s, memory: %s", cpu, memory)
	}

	// on systemd, every pid is in a unified cgroup hierarchy (name=systemd as seen in systemd-cgls)

                return;
            case INSTRUMENTATION_MARKER:
            case TYPE_HIERARCHY_ANALYSIS_DATA:
                // We don't need to do anything with the marker file and type hierarchy
                return;
            default:
                throw new IllegalStateException("Unexpected input type: " + inputType);
        }
    }

        if (!watchedFiles.equals(oldWatchedFiles)) {
            updateWatchesOnChangedWatchedFiles(watchedFiles);
        }

        // Probe every hierarchy that is watched, even ones nested inside others
        ImmutableSet<File> oldProbedHierarchies = probedHierarchies;
        probedHierarchies = watchableHierarchies.stream()
            .filter(watchedFiles::contains)

     * slightly increasing the speed a test class runs, especially one with many test methods defined on itself or in its type hierarchy.
     */
    private final static Set<String> EXTRACTED_JARS = new HashSet<>();
    private final TestDirectoryProvider testDirectoryProvider;

    private Class<?> declaringTestClass;

[[sec:settings_file]]
== Always define a settings file

Gradle tries to locate a `settings.gradle` (Groovy DSL) or a `settings.gradle.kts` (Kotlin DSL) file with every invocation of the build.
For that purpose, the runtime walks the hierarchy of the directory tree up to the root directory.
The algorithm stops searching as soon as it finds the settings file.

Always add a `settings.gradle` to the root directory of your build to avoid the initial performance impact.

import java.util.List;
import java.util.Set;
import java.util.stream.Collectors;

/**
 * A factory for a worker process which loads the application classes using the JVM's system ClassLoader.
 *
 * <p>Class loader hierarchy:</p>
 * <pre>
 *                       jvm bootstrap
 *                             |
 *                             |
 *                        jvm system
 *           (GradleWorkerMain, application classes)

 *
 * The realised part is about the application of {@link VariantMetadataRules} which are applied eagerly
 * to configuration or variant data.
 *
 * This type hierarchy is used whenever the {@code ModuleComponentResolveMetadata} needs to outlive
 * the build execution.
 */
public abstract class AbstractRealisedModuleComponentResolveMetadata extends AbstractModuleComponentResolveMetadata {

        runtime.artifacts.name.name == ["runtime.jar"]
        runtime.excludes.empty
        def defaultConfig = immutable.getConfiguration("default")
        defaultConfig.hierarchy as List == ["default", "runtime"]
        defaultConfig.transitive
        defaultConfig.visible
        defaultConfig.artifacts.name.name == ["api.jar", "runtime.jar"]
        defaultConfig.excludes.empty

        and:

 * #getRepositories()} method to manage the repositories.</p>
 *
 * <h3>Multi-project Builds</h3>
 *
 * <p>Projects are arranged into a hierarchy of projects. A project has a name, and a fully qualified path which
 * uniquely identifies it in the hierarchy.</p>
 *
 * <h3>Plugins</h3>
 *
 * <p>
 * Plugins can be used to modularise and reuse project configuration.

    get() = accessorTypePrecedenceSequence().find { it.isKotlinPublic }


internal
fun Class<*>.accessorTypePrecedenceSequence(): Sequence<Class<*>> = sequence {

    // First, all the classes in the hierarchy, subclasses before superclasses
    val classes = ancestorClassesIncludingSelf.toList()
    yieldAll(classes)

    // Then all supported interfaces sorted by subtyping (subtypes before supertypes)