</pre>

<h4 id="Operator_precedence">Operator precedence</h4>
<p>
Unary operators have the highest precedence.
As the  <code>++</code> and <code>--</code> operators form
statements, not expressions, they fall
outside the operator hierarchy.
As a consequence, statement <code>*p++</code> is the same as <code>(*p)++</code>.
</p>

<p>
There are five precedence levels for binary operators.

means that if a header file foo/bar.h exists both in the source
directory and also in the system include directory (or some other place
specified by a -I flag), then "#include <foo/bar.h>" will always find the
local version in preference to any other version.

The cgo tool is enabled by default for native builds on systems where
it is expected to work. It is disabled by default when cross-compiling

	//
	// The following are semantically equivalent:
	//  h.Xattrs[key] = value
	//  h.PAXRecords["SCHILY.xattr."+key] = value
	//
	// When Writer.WriteHeader is called, the contents of Xattrs will take
	// precedence over those in PAXRecords.
	//
	// Deprecated: Use PAXRecords instead.
	Xattrs map[string]string

	// PAXRecords is a map of PAX extended header records.
	//

// much practical consequence because the expressions we
// see in assembly code are simple, but for the record:
//
// 1) Evaluation uses uint64; the old one used int64.
// 2) Precedence uses Go rules not C rules.

// expr = term | term ('+' | '-' | '|' | '^') term.
func (p *Parser) expr() uint64 {
	value := p.term()
	for {
		switch p.peek() {
		case '+':
			p.next()

</pre>

<h4 id="Operator_precedence">Operator precedence</h4>
<p>
Unary operators have the highest precedence.
As the  <code>++</code> and <code>--</code> operators form
statements, not expressions, they fall
outside the operator hierarchy.
As a consequence, statement <code>*p++</code> is the same as <code>(*p)++</code>.
</p>
<p>
There are five precedence levels for binary operators.

it is a distinct program, so there are some differences.
One is in constant evaluation.
Constant expressions in the assembler are parsed using Go's operator
precedence, not the C-like precedence of the original.
Thus <code>3&amp;1&lt;&lt;2</code> is 4, not 0—it parses as <code>(3&amp;1)&lt;&lt;2</code>
not <code>3&amp;(1&lt;&lt;2)</code>.
Also, constants are always evaluated as 64-bit unsigned integers.

pkg go/token, method (Position) String() string
pkg go/token, method (Token) IsKeyword() bool
pkg go/token, method (Token) IsLiteral() bool
pkg go/token, method (Token) IsOperator() bool
pkg go/token, method (Token) Precedence() int
pkg go/token, method (Token) String() string
pkg go/token, type File struct
pkg go/token, type FileSet struct
pkg go/token, type Pos int
pkg go/token, type Position struct

		fh.Flags |= 0x800
	}

	fh.CreatorVersion = fh.CreatorVersion&0xff00 | zipVersion20 // preserve compatibility byte
	fh.ReaderVersion = zipVersion20

	// If Modified is set, this takes precedence over MS-DOS timestamp fields.
	if !fh.Modified.IsZero() {
		// Contrary to the FileHeader.SetModTime method, we intentionally
		// do not convert to UTC, because we assume the user intends to encode

  as in <code>/exact/match/{$}</code>.
</p>

<p>
  If two patterns overlap in the requests that they match, then the more specific pattern takes precedence.
  If neither is more specific, the patterns conflict.
  This rule generalizes the original precedence rules and maintains the property that the order in which
  patterns are registered does not matter.
</p>

<p>