required: true

  - type: textarea
    attributes:
      label: Why do we need it to be improved?
    validations:
      required: true

  - type: textarea
    attributes:
      label: Example
      description: >
        Please provide an example usage of the feature that would be different with the improvement.
      render: java
    validations:
      required: true

  - type: textarea
    attributes:

    }
    val type = source.readByte() and 0xff
    val flags = source.readByte() and 0xff
    val streamId = source.readInt() and 0x7fffffff // Ignore reserved bit.
    if (type != TYPE_WINDOW_UPDATE && logger.isLoggable(FINE)) {
      logger.fine(frameLog(true, streamId, length, type, flags))
    }

    if (requireSettings && type != TYPE_SETTINGS) {

   * @return false when EOF is reached
   */
  @Throws(IOException::class)
  fun processNextEvent(): Boolean {
    var id = lastId
    var type: String? = null
    val data = Buffer()

    while (true) {
      when (source.select(options)) {
        in 0..2 -> {
          completeEvent(id, type, data)
          return true
        }

        in 3..4 -> {
          source.readData(data)
        }

        in 5..7 -> {

    String id();

    /**
     * The language of this packaging.
     */
    @Nonnull
    default Language language() {
        return type().getLanguage();
    }

    /**
     * The type of main artifact produced by this packaging.
     */
    @Nonnull
    Type type();

    /**
     * Returns the binding to use specifically for this packaging keyed by lifecycle id.

        // ----- Credentials (super-interface) -----

        @Override
        public <T extends Credentials> T unwrap(Class<T> type) {
            if (type == null) {
                throw new NullPointerException("type");
            }
            if (type.isInstance(this)) {
                return type.cast(this);
            }
            return null;
        }

        @Override

    }

    /**
     * Creates a Type-2 message using default values from the current
     * environment.
     */
    public Type2Message() {
        this(getDefaultFlags(), null, null);
    }

    /**
     * Creates a Type-2 message in response to the given Type-1 message
     * using default values from the current environment.
     *
     * @param type1 The Type-1 message which this represents a response to.
     */

labels: ["gopls", "Tools"]
body:
  - type: markdown
    attributes:
      value: "Please answer these questions before submitting your issue. Thanks!"
  - type: textarea
    id: gopls-version
    attributes:
      label: "gopls version"
      description: "Output of `gopls -v version` on the command line"
    validations:
      required: true
  - type: textarea
    id: go-env
    attributes:

 *       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},
 *       typically because the type forbids nullable type arguments: For example, {@code

 *       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},
 *       typically because the type forbids nullable type arguments: For example, {@code

 *       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},
 *       typically because the type forbids nullable type arguments: For example, {@code