* Therefore, we can always create our own TypeVariable.
         *
         * 2. Under the JDK, the built-in TypeVariable implementation does not interoperate with
         * ours. Therefore, we have to be careful about whether we create our own TypeVariable:
         *
         * 2a. If the resolved types are identical to the original types, then we can return the

        }

        in 5..7 -> {
          data.writeByte('\n'.code) // 'data' on a line of its own.
        }

        in 8..9 -> {
          id = source.readUtf8LineStrict().takeIf { it.isNotEmpty() }
        }

        in 10..12 -> {
          id = null // 'id' on a line of its own.
        }

        in 13..14 -> {
          type = source.readUtf8LineStrict().takeIf { it.isNotEmpty() }
        }

         * Therefore, we can always create our own TypeVariable.
         *
         * 2. Under the JDK, the built-in TypeVariable implementation does not interoperate with
         * ours. Therefore, we have to be careful about whether we create our own TypeVariable:
         *
         * 2a. If the resolved types are identical to the original types, then we can return the

`MultipartBody.Builder` can build sophisticated request bodies compatible with HTML file upload forms. Each part of a multipart request body is itself a request body, and can define its own headers. If present, these headers should describe the part body, such as its `Content-Disposition`. The `Content-Length` and `Content-Type` headers are added automatically if they're available.

=== ":material-language-kotlin: Kotlin"

              <version>${surefire.toolchain.version}</version>
            </jdkToolchain>
            <includes>
              <include>${test.include}</include>
            </includes>
            <!-- By having our own entries here, we also override the default exclusion filter, which excludes all nested classes. -->
            <excludes>
              <!-- https://github.com/google/guava/issues/2840 -->

              <version>${surefire.toolchain.version}</version>
            </jdkToolchain>
            <includes>
              <include>${test.include}</include>
            </includes>
            <!-- By having our own entries here, we also override the default exclusion filter, which excludes all nested classes. -->
            <excludes>
              <!-- https://github.com/google/guava/issues/2840 -->

            lines could make c.g.c.base.testModule transitively inherit from extra modules. If some
            of those modules are ones that it uses but forgets to list in its own <inherits>, we'd
            like to get an error. Currently we do, but if we add the extra <inherits> lines, we
            won't.