blank1.go:10:9: error: invalid package name _
blank1.go:17:2: error: cannot use _ as value
blank1.go:18:7: error: cannot use _ as value
blank1.go:20:8: error: invalid use of ‘_’
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/14088044
When a floating point constant is used as an array/slice
index, gccgo prints "error: index must be integer"; gc prints
"constant 2.1 truncated to integer".
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/14044044
The select2.go test assumed that the memory allocated between
its two samplings of runtime.ReadMemStats is strictly
increasing. To avoid failing the tests when this is not true,
a greater-than check is introduced before computing the
difference in allocated memory.
R=golang-dev, r, cshapiro
CC=golang-dev
https://golang.org/cl/13701046
This eliminates ~75% of the nil checks being emitted,
on all architectures. We can do better, but we need
a bit more general support from the compiler, and
I don't want to do that so close to Go 1.2.
What's here is simple but effective and safe.
A few small code generation cleanups were required
to make the analysis consistent on all systems about
which nil checks are omitted, at least in the test.
Fixes#6019.
R=ken2
CC=golang-dev
https://golang.org/cl/13334052
The implementation of division in the 5 toolchain is a bit too magical.
Hide the magic from the traceback routines.
Also add a test for the results of the software divide routine.
Fixes#5805.
R=golang-dev, minux.ma
CC=golang-dev
https://golang.org/cl/13239052
Bug #1:
Issue 5406 identified an interesting case:
defer iface.M()
may end up calling a wrapper that copies an indirect receiver
from the iface value and then calls the real M method. That's
two calls down, not just one, and so recover() == nil always
in the real M method, even during a panic.
[For the purposes of this entire discussion, a wrapper's
implementation is a function containing an ordinary call, not
the optimized tail call form that is somtimes possible. The
tail call does not create a second frame, so it is already
handled correctly.]
Fix this bug by introducing g->panicwrap, which counts the
number of bytes on current stack segment that are due to
wrapper calls that should not count against the recover
check. All wrapper functions must now adjust g->panicwrap up
on entry and back down on exit. This adds slightly to their
expense; on the x86 it is a single instruction at entry and
exit; on the ARM it is three. However, the alternative is to
make a call to recover depend on being able to walk the stack,
which I very much want to avoid. We have enough problems
walking the stack for garbage collection and profiling.
Also, if performance is critical in a specific case, it is already
faster to use a pointer receiver and avoid this kind of wrapper
entirely.
Bug #2:
The old code, which did not consider the possibility of two
calls, already contained a check to see if the call had split
its stack and so the panic-created segment was one behind the
current segment. In the wrapper case, both of the two calls
might split their stacks, so the panic-created segment can be
two behind the current segment.
Fix this by propagating the Stktop.panic flag forward during
stack splits instead of looking backward during recover.
Fixes#5406.
R=golang-dev, iant
CC=golang-dev
https://golang.org/cl/13367052
These tests were suggested in golang.org/issue/6080.
They were fixed as part of the new nil pointer checks
that I added a few weeks ago.
Recording the tests as part of marking the issue closed.
Fixes#6080.
R=golang-dev, r, bradfitz
CC=golang-dev
https://golang.org/cl/13255049
Types in function scope can have methods on them if they embed another type, but we didn't make the name unique, meaning that 2 identically named types in different functions would conflict with eachother.
Fixes#6269.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/13326045
The compiler computes initialization order by finding
a spanning tree between a package's global variables.
But it does so by walking both variables and functions
and stops detecting cycles between variables when they
mix with a cycle of mutually recursive functions.
Fixes#4847.
R=golang-dev, daniel.morsing, rsc
CC=golang-dev
https://golang.org/cl/9663047
syntax/*: update messages
sliceerr3.go: bizarre new error fixed by deleting a space.
I could have sworn I ran all.bash before submitting the CL that triggered these.
TBR=golang-dev@googlegroups.com
R=golang-dev
CC=golang-dev
https://golang.org/cl/12812044
See golang.org/s/go12nil.
This CL is about getting all the right checks inserted.
A followup CL will add an optimization pass to
remove redundant checks.
R=ken2
CC=golang-dev
https://golang.org/cl/12970043
Individual variables bigger than 10 MB are now
moved to the heap, as if they had escaped on
their own.
This avoids ridiculous stacks for programs that
do things like
x := [1<<30]byte{}
... use x ...
If 10 MB is too small, we can raise the limit.
Fixes#6077.
R=ken2
CC=golang-dev
https://golang.org/cl/12650045
The gc compiler only gives an error about an unused label if
it has not given any errors in an earlier pass. Remove all
unused labels in this test because they don't test anything
useful and they cause gccgo to give unexpected errors.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/12580044
The gc compiler only gives an error about fallthrough in a
type switch if it has not given any errors in an earlier pass.
Remove all functions in this test that use fallthrough in a
type switch because they don't test anything useful and they
cause gccgo to give unexpected errors.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/12614043
Backends do not exactly expect receiving binary operators with
constant operands or use workarounds to move them to
register/stack in order to handle them.
Fixes#5841.
R=golang-dev, daniel.morsing, rsc
CC=golang-dev
https://golang.org/cl/11107044
