// Amount fields.
		//
		// arg1 is rotated left by the rotation amount then the bits from the start
		// bit to the end bit (inclusive) are combined with arg0 using the logical
		// operation specified. Bit indices are specified from left to right - the
		// MSB is 0 and the LSB is 63.
		//
		// Examples:
		//               |          aux         |

  }

  @Override
  public ImmutableSortedSet<K> descendingKeySet() {
    return keySet.descendingSet();
  }

  /**
   * Serialized type for all ImmutableSortedMap instances. It captures the logical contents and they
   * are reconstructed using public factory methods. This ensures that the implementation types
   * remain as implementation details.
   */
  @J2ktIncompatible // serialization

	// up with the correct number, but it doesn't matter, because EvBatch has
	// custom logic for parsing.
	//
	// Note that because we're adding 1, inlineArgs == 3 describes the largest
	// number of logical arguments that isn't length-prefixed, even though the
	// value 3 on the wire indicates length-prefixing. For us, that becomes narg
	// == 4.
	narg := b>>6 + 1

		last = w.List[len(w.List)-1]
	}
	if node, ok := node.(*CondBreak); ok {
		w.CanFail = true
		if last, ok := last.(*CondBreak); ok {
			// Add to the previous "if <cond> { break }" via a
			// logical OR, which will save verbosity.
			last.Cond = &ast.BinaryExpr{
				Op: token.LOR,
				X:  last.Cond,
				Y:  node.Cond,
			}
			return
		}
	}

	w.List = append(w.List, node)
}

	// size of bucket hash table
	buckHashSize = 179999

	// maxSkip is to account for deferred inline expansion
	// when using frame pointer unwinding. We record the stack
	// with "physical" frame pointers but handle skipping "logical"
	// frames at some point after collecting the stack. So
	// we need extra space in order to avoid getting fewer than the
	// desired maximum number of frames after expansion.

ble:true},parentNode:{get:function(){return TreeApi.Logical.getParentNode(this.node);},configurable:true},firstChild:{get:function(){return TreeApi.Logical.getFirstChild(this.node);},configurable:true},lastChild:{get:function(){return TreeApi.Logical.getLastChild(this.node);},configurable:true},nextSibling:{get:function(){return TreeApi.Logical.getNextSibling(this.node);},configurable:true},previousSibling:{get:function(){return TreeApi.Logical.getPreviousSibling(this.node);},configurable:true},...

        "properties": {
          "ports": {

	VREV32	V5.B16, V5.B16                  // a508206e
	VREV64	V2.S2, V3.S2                    // 4308a00e
	VREV64	V2.S4, V3.S4                    // 4308a04e

// logical ops
//
// make sure constants get encoded into an instruction when it could
	AND	R1@>33, R2
	AND	$(1<<63), R1                        // AND	$-9223372036854775808, R1       // 21004192

                maxLength: 253
                minLength: 1
                type: string
              listeners:
                description: "Listeners associated with this Gateway. Listeners define
                  logical endpoints that are bound on this Gateway's addresses. At
                  least one Listener MUST be specified. \n Each Listener in a set
                  of Listeners (for example, in a single Gateway) MUST be _distinct_,

See <<#project_builddir, the deprecation entry>> for details.

==== `TestLauncher` API no longer ignores build failures

The `TestLauncher` interface is part of the Tooling API, specialized for running tests.
It is a logical extension of the `BuildLauncher` that can only launch tasks.
A discrepancy has been reported in their behavior: if the same failing test is executed, `BuildLauncher` will report a build failure but `TestLauncher` won't.