* matching implementation of the {@link ScriptingLanguage} SPI. If no provider
 * implementations matches for a given file name, handling falls back to the
 * {@link DefaultScriptPluginFactory}. This approach allows users to name build scripts
 * with a suffix of choice, e.g. "build.groovy" or "my.build" instead of the typical
 * "build.gradle" while preserving default behaviour which is to fallback to Groovy support.
 *

            // we called sizeIfKnown and when we started reading the file (or I guess if
            // maxCharsPerByte is wrong)
            // Fallback to an incremental approach
            StringBuilder builder = new StringBuilder(bufIndex + 32);
            builder.append(buffer, 0, bufIndex);
            buffer = null; // release for gc
            CharStreams.copy(reader, builder);

			),
		)
	}

	if pvSpec.PersistentVolumeReclaimPolicy == api.PersistentVolumeReclaimRecycle {
		warnings = append(warnings, fmt.Sprintf("%s: The Recycle reclaim policy is deprecated. Instead, the recommended approach is to use dynamic provisioning.", fieldPath.Child("spec", "persistentVolumeReclaimPolicy")))
	}

	if pvSpec.NodeAffinity != nil && pvSpec.NodeAffinity.Required != nil {

// the public interface by constructing an *os.File from a file descriptor
// opened on a socket, but the WASI preview 1 specification is too limited to
// support this approach for UDP sockets. Instead, we test the internals that
// make it possible for WASI host runtimes and guest programs to integrate
// socket extensions with the net package using net.FileConn/net.FileListener.
//

        real-world use case so the community can discuss and debate whether this feature is actually
        the *best* way to address the real use case, or whether or not a different approach might be
        more appropriate.


        It's okay if you can't provide complete context on a use case. We understand if you are not
        able to discuss the full details of what you're working on.

     */
    JS_DYNAMIC,

    /**
     * Kotlin/Native forward declaration.
     *
     * See: [Forward declarations in 1.9.20+](https://kotlinlang.org/docs/multiplatform-compatibility-guide.html#new-approach-to-forward-declarations)
     */
    NATIVE_FORWARD_DECLARATION,
}

	awsMetadataIPv6URL = "http://[fd00:ec2::254]/latest/meta-data"

	awsMetadataTokenIPv4URL = "http://169.254.169.254/latest/api/token"
	awsMetadataTokenIPv6URL = "http://[fd00:ec2::254]/latest/api/token"
)

// Approach derived from the following:
// https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/identify_ec2_instances.html
// https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instancedata-data-retrieval.html

        //and we need to have a matching descriptor to inform the user which test this output belongs to
        //we will use the current parent

        //(SF) This approach should generally work because at the moment we reset capturing output per suite
        //(see CaptureTestOutputTestResultProcessor) and that reset happens earlier in the chain.

API changes
-----------

We make changes to Guava's public [APIs][], including adding new APIs, very
carefully. Because of this, if you're interested in seeing a new feature in
Guava, the best approach is to create an [issue][] (or comment on an existing
issue if there is one) requesting the feature and describing specific use cases
for it.

If the feature has merit, it will go through a thorough process of API design

  val request: LauncherDiscoveryRequest =
    LauncherDiscoveryRequestBuilder.request()
      // TODO replace junit.jupiter.extensions.autodetection.enabled with API approach.
//    .enableImplicitConfigurationParameters(false)
      .selectors(selectors)
      .build()
  return request
}

/**