1. 26 Aug, 2019 5 commits
    • Robert Griesemer's avatar
      go/types: NewInterface/NewInterfaceType complete empty interfaces · 82d6e2ea
      Robert Griesemer authored
      When creating a new interface via the exported API calls, a shared
      empty and completed Interface value is returned if there are no
      methods or embedded interfaces. This is a minor optimization and
      matches the internal behavior when creating empty interfaces.
      
      Since calling Interface.Complete is idempotent, and since there
      are no other legitimate ways to create Interface values externally
      but via NewInterface/NewInterfaceType calls, and completed Interfaces
      are considered "immutable", this change is not expected to affect
      clients. The only observable behavior that changed is the string
      value for empty interfaces created via the above API calls; those
      empty interfaces now don't show "incomplete" anymore even before
      Interface.Complete is called. Except in special test cases, this
      behavior is unlikely to affect clients.
      
      Change-Id: Idf7f2cd112241c5b81a43b4544bbe3f2e003d8d8
      Reviewed-on: https://go-review.googlesource.com/c/go/+/191417Reviewed-by: default avatarMatthew Dempsky <mdempsky@google.com>
      82d6e2ea
    • Robert Griesemer's avatar
      go/types: allow embedding overlapping interfaces · a80c5f05
      Robert Griesemer authored
      Quietly drop duplicate methods from embedded interfaces
      if they have an identical signature to existing methods.
      
      Instead of adjusting the prior syntax-based only method set
      computation where methods don't have signature information
      (and thus where de-duplication according to the new rules
      would have been somewhat tricky to get right), this change
      completely rewrites interface method set computation, taking
      a page from the cmd/compiler's implementation. In a first
      pass, when type-checking interfaces, explicit methods and
      embedded interfaces are collected, but the interfaces are
      not "expanded", that is the final method set computation
      is done lazily, either when needed for method lookup, or
      at the end of type-checking.
      
      While this is a substantial rewrite, it allows us to get
      rid of the separate (duplicate and delicate) syntactical
      method set computation and generally simplifies checking
      of interface types significantly. A few (esoteric) test
      cases now have slightly different error messages but all
      tests that are accepted by cmd/compile are also accepted
      by go/types.
      
      (This is a replacement for golang.org/cl/190258.)
      
      Updates #6977.
      
      Change-Id: Ic8b9321374ab4f617498d97c12871b69d1119735
      Reviewed-on: https://go-review.googlesource.com/c/go/+/191257Reviewed-by: default avatarMatthew Dempsky <mdempsky@google.com>
      a80c5f05
    • Robert Griesemer's avatar
      go/types: add -halt flag to ease debugging in test mode · 89f02eb8
      Robert Griesemer authored
      Specifying -halt in `go test -run Check$ -halt` causes a panic
      upon encountering the first error. The stack trace is useful to
      determine what code path issued the error.
      
      Change-Id: I2e17e0014ba87505b01786980b98565f468065bf
      Reviewed-on: https://go-review.googlesource.com/c/go/+/190257Reviewed-by: default avatarMatthew Dempsky <mdempsky@google.com>
      89f02eb8
    • Kevin Gillette's avatar
      net/http: make docs refer to Context.Value as a getter instead of context.WithValue · 8b03a399
      Kevin Gillette authored
      The doc comments of both ServerContextKey and LocalAddrContextKey both suggest that context.WithValue can be used to access (get) properties of the server or connection. This PR fixes those comments to refer to Context.Value instead.
      
      Change-Id: I4ed383ef97ba1951f90c555243007469cfc18d4d
      GitHub-Last-Rev: 05bc3acf82322e3dc77abc7fa0412efe01a77eac
      GitHub-Pull-Request: golang/go#33833
      Reviewed-on: https://go-review.googlesource.com/c/go/+/191838Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      8b03a399
    • Andrew Bonventre's avatar
      Revert "errors: add example showing a custom error with Unwrap" · 78f6856d
      Andrew Bonventre authored
      This reverts commit 739123c3.
      
      Reason for revert: broke Windows and Plan 9 builders
      
      Fixes #33828
      
      Change-Id: I1d85c81549b1b34924fdd0ade8bf9406e5cf6555
      Reviewed-on: https://go-review.googlesource.com/c/go/+/191742
      Run-TryBot: Andrew Bonventre <andybons@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarJonathan Amsterdam <jba@google.com>
      78f6856d
  2. 25 Aug, 2019 3 commits
  3. 24 Aug, 2019 1 commit
  4. 23 Aug, 2019 4 commits
  5. 22 Aug, 2019 3 commits
  6. 21 Aug, 2019 3 commits
  7. 20 Aug, 2019 2 commits
  8. 19 Aug, 2019 1 commit
  9. 18 Aug, 2019 1 commit
  10. 16 Aug, 2019 3 commits
  11. 15 Aug, 2019 2 commits
  12. 14 Aug, 2019 2 commits
  13. 12 Aug, 2019 2 commits
    • Filippo Valsorda's avatar
      net/url: make Hostname and Port predictable for invalid Host values · 61bb56ad
      Filippo Valsorda authored
      When Host is not valid per RFC 3986, the behavior of Hostname and Port
      was wildly unpredictable, to the point that Host could have a suffix
      that didn't appear in neither Hostname nor Port.
      
      This is a security issue when applications are applying checks to Host
      and expecting them to be meaningful for the contents of Hostname.
      
      To reduce disruption, this change only aims to guarantee the following
      two security-relevant invariants.
      
      * Host is either Hostname or [Hostname] with Port empty, or
        Hostname:Port or [Hostname]:Port.
      
      * Port is only decimals.
      
      The second invariant is the one that's most likely to cause disruption,
      but I believe it's important, as it's conceivable an application might
      do a suffix check on Host and expect it to be meaningful for the
      contents of Hostname (if the suffix is not a valid port).
      
      There are three ways to ensure it.
      
      1) Reject invalid ports in Parse. Note that non-numeric ports are
         already rejected if and only if the host starts with "[".
      
      2) Consider non-numeric ports as part of Hostname, not Port.
      
      3) Allow non-numeric ports, and hope they only flow down to net/http,
         which will reject them (#14353).
      
      This change adopts both 1 and 2. We could do only the latter, but then
      these invalid hosts would flow past port checks, like in
      http_test.TestTransportRejectsAlphaPort. Non-numeric ports weren't fully
      supported anyway, because they were rejected after IPv6 literals, so
      this restores consistency. We could do only the former, but at this
      point 2) is free and might help with manually constructed Host values
      (or if we get something wrong in Parse).
      
      Note that net.SplitHostPort and net.Dial explicitly accept service names
      in place of port numbers, but this is an URL package, and RFC 3986,
      Section 3.2.3, clearly specifies ports as a number in decimal.
      
      net/http uses a mix of net.SplitHostPort and url.Parse that would
      deserve looking into, but in general it seems that it will still accept
      service names in Addr fields as they are passed to net.Listen, while
      rejecting them in URLs, which feels correct.
      
      This leaves a number of invalid URLs to reject, which however are not
      security relevant once the two invariants above hold, so can be done in
      Go 1.14: IPv6 literals without brackets (#31024), invalid IPv6 literals,
      hostnames with invalid characters, and more.
      
      Tested with 200M executions of go-fuzz and the following Fuzz function.
      
      	u, err := url.Parse(string(data))
      	if err != nil {
      		return 0
      	}
      	h := u.Hostname()
      	p := u.Port()
      
      	switch u.Host {
      	case h + ":" + p:
      		return 1
      	case "[" + h + "]:" + p:
      		return 1
      	case h:
      		fallthrough
      	case "[" + h + "]":
      		if p != "" {
      			panic("unexpected Port()")
      		}
      		return 1
      	}
      	panic("Host is not a variant of [Hostname]:Port")
      
      Fixes CVE-2019-14809
      Updates #29098
      
      Change-Id: I7ef40823dab28f29511329fa2d5a7fb10c3ec895
      Reviewed-on: https://go-review.googlesource.com/c/go/+/189258Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      61bb56ad
    • Filippo Valsorda's avatar
      src/go.mod: sync golang.org/x/net with h2_bundle.go · 45504066
      Filippo Valsorda authored
      The bundle included changes from a commit after the one referred to by
      the go.mod, probably due to cmd/bundle using the GOPATH source.
      
      Identified with the new go/packages based cmd/bundle from CL 189818.
      
      $ go get golang.org/x/net@461777fb6f
      $ go mod tidy
      $ go mod vendor
      $ go generate net/http # with CL 189818
      
      Also, updated the socks_bundle.go generate command to drop obsolete
      options and match h2_bundle.go. It caused no output changes.
      
      Updates #32031
      
      Change-Id: I0322d4e842dbfdad749455111072ca4872a62ad4
      Reviewed-on: https://go-review.googlesource.com/c/go/+/189897Reviewed-by: default avatarDmitri Shuralyov <dmitshur@golang.org>
      45504066
  14. 11 Aug, 2019 2 commits
  15. 10 Aug, 2019 1 commit
  16. 09 Aug, 2019 4 commits
  17. 08 Aug, 2019 1 commit
    • Jay Conrod's avatar
      cmd/go: improve 'go mod download' and 'go list -m' error messages · 1dc0110b
      Jay Conrod authored
      modload.ListModules now wraps errors as module.ModuleError as
      appropriate. The resulting errors always include the module path and
      will include the version, if known.
      
      'go mod download' no longer ignores errors reported by ListModules.
      Previously, it started requesting module info, go.mod, and zip. Those
      requests would fail, overwriting the original failure. They were
      usually less descriptive.
      
      'go mod download' with a module not in the build list (and no version
      query) is now an error. Previously, this was silently ignored.
      
      Fixes #30743
      
      Change-Id: Icee8c1c6c5240de135a8b6ba42d6bbcdb757cdac
      Reviewed-on: https://go-review.googlesource.com/c/go/+/189323
      Run-TryBot: Jay Conrod <jayconrod@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarBryan C. Mills <bcmills@google.com>
      1dc0110b