Need to correct for deferproc's extra 2 words of stack or in some
cases (such as memory profiling) traceback can cause a crash.
Also bulletproof the closure test.
R=rsc
CC=golang-dev
https://golang.org/cl/2138047
named1.go:40:11: error: argument 1 has incompatible type (cannot use type bool as type Bool)
named1.go:41:11: error: argument 1 has incompatible type (cannot use type bool as type Bool)
named1.go:43:7: error: incompatible types in assignment (cannot use type bool as type Bool)
named1.go:44:12: error: argument 4 has incompatible type (cannot use type Bool as type bool)
named1.go:46:4: error: incompatible types in assignment (cannot use type bool as type Bool)
named1.go:48:11: error: argument 1 has incompatible type (cannot use type bool as type Bool)
named1.go:50:7: error: incompatible types in assignment (cannot use type bool as type Bool)
named1.go:54:7: error: incompatible types in assignment (cannot use type bool as type Bool)
named1.go:60:7: error: incompatible types in assignment (cannot use type bool as type Bool)
named1.go:63:9: error: argument 1 has incompatible type (cannot use type bool as type Bool)
named1.go:64:4: error: incompatible types in assignment (cannot use type bool as type Bool)
named1.go:67:17: error: invalid type conversion (cannot use type Slice as type String)
R=rsc
CC=golang-dev
https://golang.org/cl/2146044
explicit.go:36:4: error: incompatible types in assignment (need explicit conversion)
explicit.go:41:4: error: incompatible types in assignment (type has no methods)
explicit.go:42:4: error: incompatible types in assignment (need explicit conversion)
explicit.go:45:5: error: incompatible types in assignment (need explicit conversion; missing method ‘N’)
explicit.go:48:9: error: invalid type conversion (need explicit conversion; missing method ‘N’)
explicit.go:51:4: error: incompatible types in assignment
explicit.go:51:7: error: invalid type conversion (need explicit conversion)
explicit.go:57:10: error: impossible type assertion: type does not implement interface (type has no methods)
explicit.go:62:10: error: impossible type assertion: type does not implement interface (incompatible type for method ‘M’ (different number of parameters))
explicit.go:67:5: error: incompatible type in initialization (type has no methods)
explicit.go:68:5: error: incompatible type in initialization (incompatible type for method ‘M’ (different number of parameters))
explicit.go:70:11: error: invalid type conversion (type has no methods)
explicit.go:71:11: error: invalid type conversion (incompatible type for method ‘M’ (different number of parameters))
R=rsc
CC=golang-dev
https://golang.org/cl/2139044
Use OS rather than compiler specific flag the same way that
__FreeBSD__, __APPLE__, __OpenBSD__, and __linux__ are used.
_WIN32 is defined by GCC (and others) on windows for Win32
and Win64 applications. _WIN32 is set by default for several
other windows based compilers: DMC, MSVC, Intel, Watcom, LCC.
Although the change is for consistency, it allows the Go tools
to be compiled with non-Mingw GCC distributions and non-GCC
compilers that support the GCC extensions.
R=rsc, brainman, vcc
CC=golang-dev
https://golang.org/cl/2168043
bug299.go:16:2: error: expected field name
bug299.go:17:2: error: expected field name
bug299.go:18:3: error: expected field name
bug299.go:25:9: error: expected receiver name or type
bug299.go:26:10: error: expected receiver name or type
bug299.go:27:9: error: expected receiver name or type
R=rsc
CC=golang-dev
https://golang.org/cl/2150044
- in prep. for some restructuring to be able to better deal
with very large file systems
- moved a utility function into index.go
- no functionality changes, only code reorg.
R=r, adg1
CC=golang-dev
https://golang.org/cl/2098044
Fix building on GNU Make 3.82 (caused by mixed implicit and normal
rules).
The issue was introduced in changeset 6110:ca0beac3b543.
R=rsc
CC=golang-dev
https://golang.org/cl/2100044
Old code was using recursion to traverse object graph.
New code uses an explicit stack, cutting the per-pointer
footprint to two words during the recursion and avoiding
the standard allocator and stack splitting code.
in test/garbage:
Reduces parser runtime by 2-3%
Reduces Peano runtime by 40%
Increases tree runtime by 4-5%
R=r
CC=golang-dev
https://golang.org/cl/2150042
Also add exporter.Drain() to wait for completion.
This makes it possible for an Exporter to fire off a message
and wait (by calling Drain) for the message to be received,
even if a client has yet to call to retrieve it.
Once this design is settled, I'll do the same for import send.
Testing strategies welcome. I have some working stand-alone
tests.
R=rsc
CC=golang-dev
https://golang.org/cl/2137041
