There's no need for the 16-bit arithmetic here,
and it tickles a long-standing compiler bug.
Fix the exp code not to use 16-bit math and
create an explicit test for the compiler bug.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/6256048
Preserve test.
changeset: 11593:f1deaf35e1d1
user: Luuk van Dijk <lvd@golang.org>
date: Tue Jan 17 10:00:57 2012 +0100
summary: gc: fix infinite recursion for embedded interfaces
This is causing 'interface type loop' errors during compilation
of a complex program. I don't understand what's happening
well enough to boil it down to a simple test case, but undoing
this change fixes the problem.
The change being undone is fixing a corner case (uses of
pointer to interface in an interface definition) that basically
only comes up in erroneous Go programs. Let's not try to
fix this again until after Go 1.
Unfixes issue 1909.
TBR=lvd
CC=golang-dev
https://golang.org/cl/5555063
The spec says that all methods are inherited from an anonymous
field. There is no exception for non-exported methods.
This is related to issue 1536.
R=rsc
CC=golang-dev
https://golang.org/cl/5012043
The spec was adjusted in commit df410d6a4842 to allow the
implicit assignment of strutures with unexported fields in
method receivers. This change updates the compiler.
Also moved bug322 into fixedbugs and updated golden.out
to reflect the removal of the last known bug.
Fixes#1402.
R=golang-dev, gri, rsc
CC=golang-dev
https://golang.org/cl/4526069
go/types: update for export data format change
reflect: require package qualifiers to match during interface check
runtime: require package qualifiers to match during interface check
test: fixed bug324, adapt to be silent
Fixes#1550.
Issue 1536 remains open.
R=gri, ken2, r
CC=golang-dev
https://golang.org/cl/4442071
Failing at compile time requires that for each conversion
between two interface types the compiler compare the sets of
unexported methods to see if they come from different
packages. Since this test will fail approximately never on
real code, and since it can't catch all cases of the problem,
I don't think it's worth testing in the compiler. This CL
changes this test to look for a run-time panic rather than a
compile-time error.
R=gri, rsc1, iant2, rsc
CC=golang-dev
https://golang.org/cl/4332041
Also: renamed fixedbugs/bug322.go to fixedbugs/bug323.go
because we already have a bugs/bug322.go and bug322.dir.
R=rsc
CC=golang-dev
https://golang.org/cl/4219044
cc: same
runtime: test cc alignment (required moving #define of offsetof to runtime.h)
fix bug260
Fixes#482.
Fixes#609.
R=ken2, r
CC=golang-dev
https://golang.org/cl/3563042
* Code for assignment, conversions now mirrors spec.
* Changed some snprint -> smprint.
* Renamed runtime functions to separate
interface conversions from type assertions:
convT2I, assertI2T, etc.
* Correct checking of \U sequences.
Fixes#840.
Fixes#830.
Fixes#778.
R=ken2
CC=golang-dev
https://golang.org/cl/1303042
I got it wrong because gccgo was incorrectly failing to clear
the value when a nonblocking receive did not receive
anything.
R=rsc
CC=golang-dev
https://golang.org/cl/194161
