Skip to content

G
go
Switch branch/tag
  1. 30 May, 2014 1 commit
  3. 29 May, 2014 2 commits
    • Russ Cox's avatar
      cmd/gc: fix x=x crash · 89d46fed
      Russ Cox authored 
      [Same as CL 102820043 except applied changes to 6g/gsubr.c
also to 5g/gsubr.c and 8g/gsubr.c. The problem I had last night
trying to do that was that 8g's copy of nodarg has different
(but equivalent) control flow and I was pasting the new code
into the wrong place.]

Description from CL 102820043:

The 'nodarg' function is used to obtain a Node*
representing a function argument or result.
It returned a brand new Node*, but that violates
the guarantee in most places in the compiler that
two Node*s refer to the same variable if and only if
they are the same Node* pointer. Reestablish that
invariant by making nodarg return a preexisting
named variable if present.

Having fixed that, avoid any copy during x=x in
componentgen, because the VARDEF we emit
before the copy marks the lhs x as dead incorrectly.

The change in walk.c avoids modifying the result
of nodarg. This was the only place in the compiler
that did so.

Fixes #8097.

LGTM=khr
R=golang-codereviews, khr
CC=golang-codereviews, iant, khr, r
https://golang.org/cl/103750043
      89d46fed
    • Russ Cox's avatar
      undo CL 102820043 / b0ce6dbafc18 · 9dd062b8
      Russ Cox authored 
      Breaks 386 and arm builds.
The obvious reason is that this CL only edited 6g/gsubr.c
and failed to edit 5g/gsubr.c and 8g/gsubr.c.
However, the obvious CL applying the same edit to those
files (CL 101900043) causes mysterious build failures
in various of the standard package tests, usually involving
reflect. Something deep and subtle is broken but only on
the 32-bit systems.

Undo this CL for now.

««« original CL description
cmd/gc: fix x=x crash

The 'nodarg' function is used to obtain a Node*
representing a function argument or result.
It returned a brand new Node*, but that violates
the guarantee in most places in the compiler that
two Node*s refer to the same variable if and only if
they are the same Node* pointer. Reestablish that
invariant by making nodarg return a preexisting
named variable if present.

Having fixed that, avoid any copy during x=x in
componentgen, because the VARDEF we emit
before the copy marks the lhs x as dead incorrectly.

The change in walk.c avoids modifying the result
of nodarg. This was the only place in the compiler
that did so.

Fixes #8097.

LGTM=r, khr
R=golang-codereviews, r, khr
CC=golang-codereviews, iant
https://golang.org/cl/102820043
»»»

TBR=r
CC=golang-codereviews, khr
https://golang.org/cl/95660043
      9dd062b8
  5. 28 May, 2014 17 commits
  7. 27 May, 2014 3 commits
  9. 26 May, 2014 1 commit
  11. 24 May, 2014 2 commits
  13. 23 May, 2014 1 commit
  15. 22 May, 2014 2 commits
    • Robert Griesemer's avatar
      spec: explicitly disallow blank methods in interface types · 2c83f1ea
      Robert Griesemer authored 
      The spec was unclear about whether blank methods should be
permitted in interface types. gccgo permits at most one, gc
crashes if there are more than one, go/types permits at most
one.

Discussion:

Since method sets of non-interface types never contain methods
with blank names (blank methods are never declared), it is impossible
to satisfy an interface with a blank method.

It is possible to declare variables of assignable interface types
(but not necessarily identical types) containing blank methods, and
assign those variables to each other, but the values of those
variables can only be nil.

There appear to be two "reasonable" alternatives:

1) Permit at most one blank method (since method names must be unique),
and consider it part of the interface. This is what appears to happen
now, with corner-case bugs. Such interfaces can never be implemented.

2) Permit arbitrary many blank methods but ignore them. This appears
to be closer to the handling of blank identifiers in declarations.
However, an interface type literal is not a declaration (it's a type
literal). Also, for struct types, blank identifiers are not ignored;
so the analogy with declarations is flawed.

Both these alternatives don't seem to add any benefit and are likely
(if only slightly) more complicated to explain and implement than
disallowing blank methods in interfaces altogether.

Fixes #6604.

LGTM=r, rsc, iant
R=r, rsc, ken, iant
CC=golang-codereviews
https://golang.org/cl/99410046
      2c83f1ea
    • Russ Cox's avatar
      doc/go1.3.html: change uintptr to integer in unsafe.Pointer section · 8d8dab34
      Russ Cox authored 
      The key property here is what the bit pattern represents,
not what its type is. Storing 5 into a pointer is the problem.
Storing a uintptr that holds pointer bits back into a pointer
is not as much of a problem, and not what we are claiming
the runtime will detect.

Longer discussion at
https://groups.google.com/d/msg/golang-nuts/dIGISmr9hw0/0jO4ce85Eh0J

LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/98370045
      8d8dab34
  17. 21 May, 2014 11 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7