Change-Id: I12a43b15e81a5e0b174c1c49e77f8307c567233b
Reviewed-on: https://go-review.googlesource.com/17697Reviewed-by: Rob Pike <r@golang.org>

This is a simple change to the command that should resolve problems like finding
vendored packages before their non-vendored siblings. By searching in breadth-first
order, we find the matching package lowest in the hierarchy, which is more likely
to be correct than the deeper one, such as a vendored package, that will be found
in a depth-first scan.

This may be sufficient to resolve the issue, and has the merit that it is very easy
to explain. I will leave the issue open for now in case my intuition is wrong.

Update #12423

Change-Id: Icf69e8beb1845277203fcb7d19ffb7cca9fa41f5
Reviewed-on: https://go-review.googlesource.com/17691Reviewed-by: Russ Cox <rsc@golang.org>

Fixes #13559.

Change-Id: I6fe8b5083192e8eb6c1b3ca1919fde81a00ccb7e
Reviewed-on: https://go-review.googlesource.com/17695
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>

The current implementation including Go 1.5 through 1.5.2 misuses
Windows API and mishandles the returned values from GetAdapterAddresses
on Windows. This change fixes various issues related to network facility
information by readjusting interface and interface address parsers.

Updates #5395.
Updates #10530.
Updates #12301.
Updates #12551.
Updates #13542.
Fixes #12691.
Fixes #12811.
Fixes #13476.
Fixes #13544.

Also fixes fragile screen scraping test cases in net_windows_test.go.

Additional information for reviewers:

It seems like almost all the issues above have the same root cause and
it is misunderstanding of Windows API. If my interpretation of the
information on MSDN is correctly, current implementation contains the
following bugs:

- SIO_GET_INTERFACE_LIST should not be used for IPv6. The behavior of
  SIO_GET_INTERFACE_LIST is different on kernels and probably it doesn't
  work correctly for IPv6 on old kernels such as Windows XP w/ SP2.
  Unfortunately MSDN doesn't describe the detail of
  SIO_GET_INTERFACE_LIST, but information on the net suggests so.

- Fetching IP_ADAPTER_ADDRESSES structures with fixed size area may not
  work when using IPv6. IPv6 generates ton of interface addresses for
  various addressing scopes. We need to adjust the area appropriately.

- PhysicalAddress field of IP_ADAPTER_ADDRESSES structure may have extra
  space. We cannot ignore PhysicalAddressLength field of
  IP_ADAPTER_ADDRESS structure.

- Flags field of IP_ADAPTER_ADDRESSES structure doesn't represent any of
  administratively and operatinal statuses. It just represents settings
  for windows network adapter.

- MTU field of IP_ADAPTER_ADDRESSES structure may have a uint32(-1) on
  64-bit platform. We need to convert the value to interger
  appropriately.

- IfType field of IP_ADAPTER_ADDRESSES structure is not a bit field.
  Bitwire operation for the field is completely wrong.

- OperStatus field of IP_ADAPTER_ADDRESSES structure is not a bit field.
  Bitwire operation for the field is completely wrong.

- IPv6IfIndex field of IP_ADAPTER_ADDRESSES structure is just a
  substitute for IfIndex field. We cannot prefer IPv6IfIndex to IfIndex.

- Windows XP, 2003 server and below don't set OnLinkPrefixLength field
  of IP_ADAPTER_UNICAST_ADDRESS structure. We cannot rely on the field
  on old kernels. We can use FirstPrefix field of IP_ADAPTER_ADDRESSES
  structure and IP_ADAPTER_PREFIX structure instead.

- Length field of IP_ADAPTER_{UNICAST,ANYCAST,MULTICAST}_ADDRESS
  sturecures doesn't represent an address prefix length. It just
  represents a socket address length.

Change-Id: Icabdaf7bd1d41360a981d2dad0b830b02b584528
Reviewed-on: https://go-review.googlesource.com/17412Reviewed-by: Alex Brainman <alex.brainman@gmail.com>

Failing ones are marked skipped.

Fixes #13543 (was just a test issue)
Updates #13555 (to be fixed later)
Updates #13556 (to be fixed later)
Updates #13557 (to be fixed later)
Fixes bug in golang.org/cl/17428 (http1 now uses HTTP status 431, not 413)

Change-Id: I8f7431fee35f2fc081cfe2c232ae75a00800a60b
Reviewed-on: https://go-review.googlesource.com/17683Reviewed-by: Blake Mizerany <blake.mizerany@gmail.com>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: Burcu Dogan <jbd@google.com>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

This code used to be necessary because of the error messages generated
by the YACC-based parser, but they're no longer relevant under the new
recursive descent parser:

  - LBRACE no longer exists, so "{ or {" can never occur.

  - The parser never generates error messages about "@" or "?" now
    (except in import sections, where they're actually legitimate).

  - The s/LLITERAL/litbuf/ substitution is handled in p.syntax_error.

Change-Id: Id39f747e4aa492c5830d14a47b161920bd4589ad
Reviewed-on: https://go-review.googlesource.com/17690Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

When using GOEXPERIMENT=fieldtrack, we can see AUSEFIELD instructions.
We generally want to ignore them.

No tests because as far as I can tell there are no tests for
GOEXPERIMENT=fieldtrack.

Change-Id: Iee26f25592158e5db691a36cf8d77fc54d051314
Reviewed-on: https://go-review.googlesource.com/17610Reviewed-by: David Symonds <dsymonds@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Fixes #13550

Change-Id: I407daad8b94f6773d7949ba27981d26cbfd2cdf4
Reviewed-on: https://go-review.googlesource.com/17682Reviewed-by: Russ Cox <rsc@golang.org>

Fixes #12796
Updates #13444

Change-Id: I56840c0baf9b32a683086a80f5db1c5ea0a7aedf
Reviewed-on: https://go-review.googlesource.com/17680Reviewed-by: Russ Cox <rsc@golang.org>

Found by github user asukakenji.

Change-Id: I4c76316b69e8a243fb6bf280283f3722e728d853
Reviewed-on: https://go-review.googlesource.com/17641Reviewed-by: Robert Griesemer <gri@golang.org>

Change-Id: I6427b0914fc4ccd9b841eae3aefe3b7a355fc436
Reviewed-on: https://go-review.googlesource.com/17596
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Use Windows getmac command to verify interface
MAC addresses net package returns.

The test is to be enabled once issue #12691 is fixed.

Updates #12691

Change-Id: Ic28c83303590cb4d48ee025250d4b6e30683bfd4
Reviewed-on: https://go-review.googlesource.com/17632Reviewed-by: Mikio Hara <mikioh.mikioh@gmail.com>
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

EvalSymlinks code assumes that Join has a bug
(see issue #11551 for details). But issue #11551 has
been fixed. Remove the workaround so it does not
confuses us when we read code next time.

Change-Id: I06bea20189f01f9922237c05516847353d8e4736
Reviewed-on: https://go-review.googlesource.com/17620Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Change-Id: I1164c7a76cf6e6c48ca5153d4c163f5962c4f0cd
Reviewed-on: https://go-review.googlesource.com/17622Reviewed-by: Dave Cheney <dave@cheney.net>

Use windows netsh command to verify interface
addresses and netmasks net package returns.

The test is to be enabled once issue #12811
is fixed.

Updates #12811

Change-Id: I191e350a1403e5133791d4ec59561fefa24f5c61
Reviewed-on: https://go-review.googlesource.com/17478Reviewed-by: Mikio Hara <mikioh.mikioh@gmail.com>
Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Another (historic) artifact due to partially resolving symbols too early.

Fixes #13539.

Change-Id: Ie720c491cfa399599454f384b3a9735e75d4e8f1
Reviewed-on: https://go-review.googlesource.com/17600
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Change-Id: I21317e3f60502759efc026cdfdb0b1d5f411cae9
Reviewed-on: https://go-review.googlesource.com/17521
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Change-Id: I345b6ea7024a1c85c805b2d2e22f9f79aeca5816
Reviewed-on: https://go-review.googlesource.com/17462
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Change-Id: If6cc1298ad550790ee981c1b5dc618a14947dc4a
Reviewed-on: https://go-review.googlesource.com/17526
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Change-Id: I181346a8d2a8a96fd790cde087c8fd73af911298
Reviewed-on: https://go-review.googlesource.com/17529
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Updates to http2's golang.org/cl/17590 (git rev 1796f9b8b)

Fixes #13495
Fixes #13532

Change-Id: I9b95ab438e1d895c75d031d8fcf2605921182a5e
Reviewed-on: https://go-review.googlesource.com/17591Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>

Change-Id: I282a399657c71f7b6406fcdde8afc82a13bdfe5f
Reviewed-on: https://go-review.googlesource.com/17530
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Change-Id: I9a1fe057f5bf008fa16577a7d71064050aea47e9
Reviewed-on: https://go-review.googlesource.com/17525
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Updates golang.org/x/net/http2 to git rev 438097d76

Fixes #13444

Change-Id: I699ac02d23b56db3e8a27d3f599ae56cd0a5b4b2
Reviewed-on: https://go-review.googlesource.com/17570Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>

This adapts pem.TestFuzz to sanitize the generated Block fields,
because the encoder and wireformat do not differentiate between nil
and empty slices and maps, while reflect.DeepEqual rightfully does.
In the commit mentioned below, we adapt quick.Value in
testing/quick to generate these value states, which had heretofore
been impossible with the standard library fuzz test facility.

This commit is a piecemeal extraction from ...

  https://go-review.googlesource.com/#/c/16470

..., which rsc requested to be separated from the nil slice and map
generations.

Change-Id: Iec751a2b0082af6e672a09dc9b7f4b4fb309e8a8
Reviewed-on: https://go-review.googlesource.com/17499Reviewed-by: Russ Cox <rsc@golang.org>

Fixes #13520.

Change-Id: Ia70cc44be3912167b369d7f74d3436331975c300
Reviewed-on: https://go-review.googlesource.com/17561Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

The orders of the curves in crypto/elliptic are all very close to a
power of two. None the less, there is a tiny bias in the private key
selection.

This change makes the distribution uniform by resampling in the case
that a private key is >= to the order of the curve. (It also switches
from using BitSize to Params().N.BitLen() because, although they're the
same value here, the latter is technically the correct thing to do.)

The private key sampling and nonce sampling in crypto/ecdsa don't have
this issue.

Fixes #11082.

Change-Id: Ie2aad563209a529fa1cab522abaf5fd505c7269a
Reviewed-on: https://go-review.googlesource.com/17460Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

Fixes #13514

Change-Id: I3903d3926ed4f5d54cfb77209d93c950b832b933
Reviewed-on: https://go-review.googlesource.com/17511Reviewed-by: Francesc Campoy Flores <campoy@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

- Only accept valid if statement syntax in go/parser.

- Check AST again in go/types since it may have been modified and the
  AST doesn't preclude other statements in the else branch of an if
  statement.

- Removed a test from gofmt which verified that old-style if statements
  permitting any statement in the else branch were correctly reformatted.
  It's been years since we switched to the current syntax; no need to
  support this anymore.

- Added a comment to go/printer.

Fixes #13475.

Change-Id: Id2c8fbcc68b719cd511027d0412a37266cceed6b
Reviewed-on: https://go-review.googlesource.com/17408Reviewed-by: Russ Cox <rsc@golang.org>

Use import paths of packages to build a shared lib name.
Use arguments for meta-packages 'std', 'cmd', and 'all'.

Fixes #12236

Change-Id: If274d63301686ef34e198287eb012f9062541ea0
Reviewed-on: https://go-review.googlesource.com/13921Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

The documentation was inconsistent. It said zero values were not sent, but
that zero-valued elements of arrays and arrays were sent. But which rule
applies if the array is all zero elements, and is therefore itself a zero value?

The answer is: the array is transmitted. In principle the other choice could
be made, but there would be considerable expense and complexity required
to implement this behavior now, not to mention worries about changes of
behavior.

Therefore we just document the situation: Arrays, slices, and maps are
always encoded. It would perhaps be nice to have sorted this out earlier,
but it was a missed opportunity.

Fixes #13378

Change-Id: I8fae345edfa707fcfa7a3e0160d87ff1ac5cc5a2
Reviewed-on: https://go-review.googlesource.com/17394Reviewed-by: Russ Cox <rsc@golang.org>

Following an empty import, a declaration involving a ? symbol
generates an internal compiler error when the name of the
symbol (in newname function).

package a
import""
var?

go.go:2: import path is empty
go.go:3: internal compiler error: newname nil

Make sure dclname is not called when the symbol is nil.
The error message is now:

go.go:2: import path is empty
go.go:3: invalid declaration
go.go:4: syntax error: unexpected EOF

This CL was initially meant to be applied to the old parser,
and has been updated to apply to the new parser.

Fixes #11610

Change-Id: I75e07622fb3af1d104e3a38c89d9e128e3b94522
Reviewed-on: https://go-review.googlesource.com/15268Reviewed-by: Russ Cox <rsc@golang.org>

Fixes #13471.

Change-Id: I232ad1729343d020254e313cfff182695ad6fc54
Reviewed-on: https://go-review.googlesource.com/17401Reviewed-by: Russ Cox <rsc@golang.org>

If reports like #13062 are really concurrent misuse of maps,
we can detect that, at least some of the time, with a cheap check.

There is an extra pair of memory writes for writing to a map,
but to the same cache line as h.count, which is often being modified anyway,
and there is an extra memory read for reading from a map,
but to the same cache line as h.count, which is always being read anyway.
So the check should be basically invisible and may help reduce the
number of "mysterious runtime crash due to map misuse" reports.

Change-Id: I0e71b0d92eaa3b7bef48bf41b0f5ab790092487e
Reviewed-on: https://go-review.googlesource.com/17501Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Austin Clements <austin@google.com>

The following code:

func n() {(interface{int})}

generates:

3: interface contains embedded non-interface int
3: type %!v(PANIC=runtime error: invalid memory address or nil pointer dereference) is not an expression

It is because the corresponding symbol (Sym field in Type object)
is nil, resulting in a panic in typefmt.

Just skip the symbol if it is nil, so that the error message becomes:

3: interface contains embedded non-interface int
3: type interface { int } is not an expression

Fixes #11614

Change-Id: I219ae7eb01edca264fad1d4a1bd261d026294b00
Reviewed-on: https://go-review.googlesource.com/14015Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>

algtype already controls the behavior of the normal map access code
paths, so it makes sense to base the decision on which optimized paths
are applicable on it too.

Enables use of optimized paths for key types like [8]byte and struct{s
string}.

Fixes #13271.

Change-Id: I48c52d97abaa7259ad5aba9641ea996a967cd359
Reviewed-on: https://go-review.googlesource.com/17464
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>

Prior behavior would show empty string when unset. In go1.5 this
would result in "off". In go1.6 this will result in "on". This
change will make empty or "0" off and "1" on for go1.5 and go1.6.
Vendor tools can then rely on this value.

Discussion:
https://groups.google.com/forum/#!topic/golang-dev/oZzcXrlRrkA

Change-Id: I7e145a32e813dfde02dc262a9186c7af28db7b92
Reviewed-on: https://go-review.googlesource.com/17487Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Change-Id: Ifa9f1ed6a3b8d3f7536f2d315259940335b0ee49
Reviewed-on: https://go-review.googlesource.com/17438Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Change-Id: I411aeaf0cf75eb8b1c9005b622f664e9f25e4a68
Reviewed-on: https://go-review.googlesource.com/17400Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Fixes #7991.
Fixes #12719.

Change-Id: I5650fa35ec5d49addeda6cc6e7fa93cfbe1cdfc0
Reviewed-on: https://go-review.googlesource.com/17385Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>