1. 14 Jan, 2019 1 commit
  2. 12 Jan, 2019 1 commit
  3. 11 Jan, 2019 2 commits
    • Sebastiaan van Stijn's avatar
      cmd/go: remove note about GOCACHE=off in docs · a2bb68de
      Sebastiaan van Stijn authored
      This patch removes mention of GOCACHE=off from the help/docs.
      It is no longer supported in Go 1.12, per the release notes.
      
      Fixes #29680
      
      Change-Id: I53ab15a62743f2e55ae1d8aa50629b1bf1ae32ad
      GitHub-Last-Rev: 31e904f51dece13645696a87b1164d86c984457f
      GitHub-Pull-Request: golang/go#29681
      Reviewed-on: https://go-review.googlesource.com/c/157517
      Run-TryBot: Elias Naur <elias.naur@gmail.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarBryan C. Mills <bcmills@google.com>
      a2bb68de
    • Austin Clements's avatar
      cmd/compile: separate data and function LSyms · a2e79571
      Austin Clements authored
      Currently, obj.Ctxt's symbol table does not distinguish between ABI0
      and ABIInternal symbols. This is *almost* okay, since a given symbol
      name in the final object file is only going to belong to one ABI or
      the other, but it requires that the compiler mark a Sym as being a
      function symbol before it retrieves its LSym. If it retrieves the LSym
      first, that LSym will be created as ABI0, and later marking the Sym as
      a function symbol won't change the LSym's ABI.
      
      Marking a Sym as a function symbol before looking up its LSym sounds
      easy, except Syms have a dual purpose: they are used just as interned
      strings (every function, variable, parameter, etc with the same
      textual name shares a Sym), and *also* to store state for whatever
      package global has that name. As a result, it's easy to slip up and
      look up an LSym when a Sym is serving as the name of a local variable,
      and then later mark it as a function when it's serving as the global
      with the name.
      
      In general, we were careful to avoid this, but #29610 demonstrates one
      case where we messed up. Because of on-demand importing from indexed
      export data, it's possible to compile a method wrapper for a type
      imported from another package before importing an init function from
      that package. If the argument of the method is named "init", the
      "init" LSym will be created as a data symbol when compiling the
      wrapper, before it gets marked as a function symbol.
      
      To fix this, we separate obj.Ctxt's symbol tables for ABI0 and
      ABIInternal symbols. This way, the compiler will simply get a
      different LSym once the Sym takes on its package-global meaning as a
      function.
      
      This fixes the above ordering issue, and means we no longer need to go
      out of our way to create the "init" function early and mark it as a
      function symbol.
      
      Fixes #29610.
      Updates #27539.
      
      Change-Id: Id9458b40017893d46ef9e4a3f9b47fc49e1ce8df
      Reviewed-on: https://go-review.googlesource.com/c/157017
      Run-TryBot: Austin Clements <austin@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarRobert Griesemer <gri@golang.org>
      a2e79571
  4. 10 Jan, 2019 5 commits
  5. 09 Jan, 2019 10 commits
  6. 08 Jan, 2019 8 commits
  7. 07 Jan, 2019 10 commits
  8. 06 Jan, 2019 1 commit
  9. 05 Jan, 2019 2 commits