Change unsafe.Pointer to be its own kind of
type, instead of making it equivalent to *any.
The change complicates import and export
but avoids the need to find all the places that
operate on pointers but should not operate on
unsafe.Pointer.
Fixes#1566. (a different way)
Fixes#1582.
R=ken2
CC=golang-dev
https://golang.org/cl/4264050
Was only breaking on some dashboard builds because
not all run the network tests.
R=bradfitzgo, bradfitzwork
CC=golang-dev
https://golang.org/cl/4240086
The parser populates all scopes for a given file (except
type-related scopes for structs, interfaces, and methods
of types) at parse time.
A new parser flag, DeclarationErrors, enables error messages
related to declaration errors (as far as it is possible to
provide them).
The resulting AST has all (non-field, non-method) identifiers
resolved that can be resolved w/o doing imports or parsing
missing package files.
The ast.File node contains the (partially complete)
package scope and a list of unresolved global identifiers.
All type-specific data structures have been removed from the AST.
The existing typechecker is functional but needs to be adjusted
(simplified) accordingly. Utility functions to resolve all
identifiers for a package (after handling imports and parsing
all package files) are missing.
Unrelated changes:
- Rename typechecker/testdata files to that they are not considered
by gofmt.
- Minor cleanups/simplifications.
Parses all .go files in src and misc without declaration errors.
Runs all tests. Changes do not affect gofmt output.
R=rsc
CC=golang-dev
https://golang.org/cl/4244049
As a data point, this enables goinstall to handle the standard
syscall package almost unchanged (there's one file with the _bsd
extension, and a .c file which isn't supposed to be compiled in).
R=rsc
CC=golang-dev
https://golang.org/cl/4259057
In June 2010 I accidentally checked in pending
changes to package rpc in a compiler CL:
https://golang.org/cl/1736041
I backed them out by hand in a followup CL:
https://golang.org/cl/1736042
That followup CL missed the lines being deleted
in this CL, spotted by Petar.
hg diff -r 5678:5683 src/cmd/prof/gopprof \
src/pkg/image/png/reader.go \
src/pkg/rpc/client.go \
src/pkg/rpc/jsonrpc/all_test.go \
src/pkg/rpc/jsonrpc/server.go \
src/pkg/rpc/server.go \
test/arm-pass.txt
confirms that these lines in server.go are the
only ones that were missed by the original followup.
Fixes#1583.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/4266046
This enables goinstall to handle .go and .c files (for cgo)
which are named after the following patterns:
name_$(GOOS).*
name_$(GOARCH).*
name_$(GOOS)_$(GOARCH).*
Files with those names are only included if the $(GOOS) and
$(GOARCH) match the current system.
R=rsc
CC=golang-dev
https://golang.org/cl/4172055
* Change use of m->g0 stack (aka scheduler stack).
* Provide runtime.mcall(f) to invoke f() on m->g0 stack.
* Replace scheduler loop entry with runtime.mcall(schedule).
Runtime.mcall eliminates the need for fake scheduler states that
exist just to run a bit of code on the m->g0 stack
(Grecovery, Gstackalloc).
The elimination of the scheduler as a loop that stops and
starts using gosave and gogo fixes a bad interaction with the
way cgo uses the m->g0 stack. Cgo runs external (gcc-compiled)
C functions on that stack, and then when calling back into Go,
it sets m->g0->sched.sp below the added call frames, so that
other uses of m->g0's stack will not interfere with those frames.
Unfortunately, gogo (longjmp) back to the scheduler loop at
this point would end up running scheduler with the lower
sp, which no longer points at a valid stack frame for
a call to scheduler. If scheduler then wrote any function call
arguments or local variables to where it expected the stack
frame to be, it would overwrite other data on the stack.
I realized this possibility while debugging a problem with
calling complex Go code in a Go -> C -> Go cgo callback.
This wasn't the bug I was looking for, it turns out, but I believe
it is a real bug nonetheless. Switching to runtime.mcall, which
only adds new frames to the stack and never jumps into
functions running in existing ones, fixes this bug.
* Move cgo-related code out of proc.c into cgocall.c.
* Add very large comment describing cgo call sequences.
* Simpilify, regularize cgo function implementations and names.
* Add test suite as misc/cgo/test.
Now the Go -> C path calls cgocall, which calls asmcgocall,
and the C -> Go path calls cgocallback, which calls cgocallbackg.
The shuffling, which affects mainly the callback case, moves
most of the callback implementation to cgocallback running
on the m->curg stack (not the m->g0 scheduler stack) and
only while accounted for with $GOMAXPROCS (between calls
to exitsyscall and entersyscall).
The previous callback code did not block in startcgocallback's
approximation to exitsyscall, so if, say, the garbage collector
were running, it would still barge in and start doing things
like call malloc. Similarly endcgocallback's approximation of
entersyscall did not call matchmg to kick off new OS threads
when necessary, which caused the bug in issue 1560.
Fixes#1560.
R=iant
CC=golang-dev
https://golang.org/cl/4253054
The Hijack functionality wasn't removed, but now you have
to test if your ResponseWriter is also a Hijacker:
func ServeHTTP(rw http.ResponseWriter, req *http.Request) {
if hj, ok := rw.(http.Hijacker); ok {
hj.Hijack(..)
}
}
R=rsc
CC=golang-dev
https://golang.org/cl/4245064
The recursive algorithm used to parse types in cgo
has a bug related to building the C type representation.
As an example, when the recursion starts at a type *T,
the C type representation won't be known until type T
itself is parsed. But then, it is possible that type T
references the type **T internally. The latter
representation is built based on the one of *T, which
started the recursion, so it won't attempt to parse it
again, and will instead use the current representation
value for *T, which is still empty at this point.
This problem was fixed by introducing a simple TypeRepr
type which builds the string representation lazily,
analogous to how the Go type information is built within
the same algorithm. This way, even if a type
representation is still unknown at some level in the
recursion, representations dependant on it can still
be created correctly.
R=rsc
CC=golang-dev
https://golang.org/cl/4244052
The path package now contains only functions which
deal with slashed paths, sensible for any OS when dealing
with network paths or URLs. OS-specific functionality
has been moved into the new path/filepath package.
This also includes fixes for godoc, goinstall and other
packages which were mixing slashed and OS-specific paths.
R=rsc, gri, mattn, brainman
CC=golang-dev
https://golang.org/cl/4252044
Cgo changed to write these files into _obj, but some
trees may still have the old ones in the source directory.
They need to be removed during make clean so that
a subsequent build will use the ones in _obj.
R=r, r2
CC=golang-dev
https://golang.org/cl/4254056
FreeBSD's execve implementation has an integer underflow in a bounds test which
causes it to erroneously think the argument list is too long when argv[0] is
longer than interpreter + path.
R=rsc, bradfitz, rsc1
CC=golang-dev
https://golang.org/cl/4259056
A change a while back stop sending data for unexported fields
but due to an oversight the type info was being sent also. It's
inconsequential but wrong to do that.
R=rsc, rh
CC=golang-dev
https://golang.org/cl/4252058
This also breaks fs_test into two parts
as the range tests test http's private httpRange
and I had to change the fs_test package from
"http" to "http_test" to use httptest which otherwise
has a cyclic depedency back on http.
Aside: we should start exposing the Range
stuff in the future.
R=rsc
CC=golang-dev
https://golang.org/cl/4261047
The test was checking for a buffer to be empty but
actually racing with the background goroutine that
was emptying it. Left a comment so that the check
is not reintroduced later.
Fixes#1557.
R=golang-dev, dsymonds
CC=golang-dev
https://golang.org/cl/4248063
Passing a frame size of 1 was causing the cgo callback
to push 1 byte of arguments onto the stack, making
the stack pointer misaligned, which had the effect of
hiding all the pointers on the stack from the garbage
collector.
SWIG only wraps calls to C++ virtual methods, so it
always has at least 1 argument, so SWIG does not need
to be fixed too.
Fixes#1328.
R=iant
CC=golang-dev
https://golang.org/cl/4261046
