Skip to content

G
go
Switch branch/tag
  1. 16 May, 2019 15 commits
  3. 15 May, 2019 8 commits
  5. 14 May, 2019 14 commits
  7. 13 May, 2019 3 commits
    • Robert Griesemer's avatar
      spec: clarify the difference between &T{} and new(T) · eebb9db0
      Robert Griesemer authored 
      Add a small paragraph and example pointing out
the difference for the case where T is a slice
or map. This is a common error for Go novices.

Fixes #29425.

Change-Id: Icdb59f25361e9f6a09b190fbfcc9ae0c7d90077b
Reviewed-on: https://go-review.googlesource.com/c/go/+/176338Reviewed-by: default avatarMatthew Dempsky <mdempsky@google.com>
      eebb9db0
    • Robert Griesemer's avatar
      spec: clarify language on package-level variable initialization · 451cf3e2
      Robert Griesemer authored 
      The very first paragraph on "Package initialization" stated that
"variables are initialized in declaration order, but after any
variables they might depend on". This phrasing was easily
misread as "declaration order is the first sorting criteria"
and then contradicted what the subsequent paragraphs spelled
out in precise detail.

Instead, variable initialization proceeds by repeatedly determining
a set of ready to initialize variables, and then selecting from that
set the variable declared earliest. That is, declaration order is the
second sorting criteria.

Also, for the purpose of variable initialization, declarations
introducing blank (_) variables are considered like any other
variables (their initialization expressions may have side-effects
and affect initialization order), even though blank identifiers
are not "declared".

This CL adds clarifying language regarding these two issues
and the supporting example.

Both gccgo and go/types implement this behavior. cmd/compile
has a long-standing issue (#22326).

The spec also did not state in which order multiple variables
initialized by a single (multi-value) initialization expression are
handled. This CL adds a clarifying paragraph: If any such variable
is initialized, all that declaration's variables are initialized at
the same time.

This behavior matches user expectation: We are not expecting to
observe partially initialized sets of variables in declarations
such as "var a, b, c = f()".

It also matches existing cmd/compile and go/types (but not gccgo)
behavior.

Finally, cmd/compile, gccgo, and go/types produce different
initialization orders in (esoteric) cases where hidden (not
detected with existing rules) dependencies exist. Added a
sentence and example clarifying how much leeway compilers have
in those situations. The goal is to preserve the ability to
use static initialization while at the same time maintain
the relative initialization order of variables with detected
dependencies.

Fixes   #31292.
Updates #22326.

Change-Id: I0a369abff8cfce27afc975998db875f5c580caa2
Reviewed-on: https://go-review.googlesource.com/c/go/+/175980Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
Reviewed-by: default avatarMatthew Dempsky <mdempsky@google.com>
      451cf3e2
    • Josh Bleecher Snyder's avatar
      cmd/compile: mark a few more tests as parallel · 5d983303
      Josh Bleecher Snyder authored 
      Reduces the time on my machine for

go clean -cache; go test -short -count=1 cmd/compile/internal/gc

from 4.7s to 3.7s.

Updates #26473

Change-Id: I9f9573675ffd6519da63961f48f61260ae4717fd
Reviewed-on: https://go-review.googlesource.com/c/go/+/176937
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      5d983303
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7