It's in an odd style and it's unclear what true purpose it serves as
a test other than to be another Go program.
R=gri
CC=golang-dev
https://golang.org/cl/5674111
* disallow embedding of C type (Fixes issue 2552)
* detect 0-length array (Fixes issue 2806)
* use typedefs when possible, to avoid attribute((unavailable)) (Fixes issue 2888)
* print Go types constructed from C types using original C types (Fixes issue 2612)
This fix changes _cgo_export.h to repeat the preamble from import "C".
Otherwise the fix to issue 2612 is impossible, since it cannot refer to
types that have not been defined. If people are using //export and
putting non-header information in the preamble, they will need to
refactor their code.
R=golang-dev, r, r
CC=golang-dev
https://golang.org/cl/5672080
morebuf holds a pc/sp from the last stack split or
reflect.call or panic/recover. If the pc is a closure,
the reference will keep it from being collected.
moreargp holds a pointer to the arguments from the
last stack split or reflect.call or panic/recover.
Normally it is a stack pointer and thus not of interest,
but in the case of reflect.call it is an allocated argument
list and holds up the arguments to the call.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5674109
The garbage collector can avoid scanning this section, with
reduces collection time as well as the number of false positives.
Helps a little bit with issue 909, but certainly does not solve it.
R=ken2
CC=golang-dev
https://golang.org/cl/5671099
We should, after Go 1, make them work the same as
package xml, that is, make them appear in the outer
struct. For now turn them off so that people do not
depend on the old behavior.
Fixing them is issue 3069.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/5656102
The m->cret word holds the C return value when returning
across a stack split boundary. It was not being cleared after
use, which means that the return value (if a C function)
or else the value of AX/R0 at the time of the last stack unsplit
was being kept alive longer than necessary. Clear it.
I think the effect here should be very small, but worth fixing
anyway.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/5677092
Very few of the compiler regression tests include a comment
saying waht they do. Many are obvious, some are anything but.
I've started with a-c in the top directory. More will follow once
we agree on the approach, correctness, and thoroughness here.
zerodivide.go sneaked in too.
R=rsc, r
CC=golang-dev
https://golang.org/cl/5656100
Because bug040.go was ignoring all error messages, the fact
that it got an error about fuction main was being ignored.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5675085
When we build the encode engine for a recursive type, we
mustn't disregard the indirections or we can try to reuse an
engine at the wrong indirection level.
Fixes#3026.
R=golang-dev, dsymonds
CC=golang-dev
https://golang.org/cl/5675087
Fix by setting the element type if we discover it's zero while building.
We could have fixed this better with foresight by doing the id setting in a
different sequence, but doing that now would break binary compatibility.
Fixes#2995.
R=golang-dev, dsymonds
CC=golang-dev
https://golang.org/cl/5675083
I am making a unilateral decision here. I could also settle for returning 0,
as long it's documented, but I argue that it's equivalent to an index
out of bounds.
Fixes#2892.
R=golang-dev, dsymonds, rsc
CC=golang-dev
https://golang.org/cl/5676079
