We replace the current Open with:
OpenFile(name, flag, perm) // same as old Open
Open(name) // same as old Open(name, O_RDONLY, 0)
Create(name) // same as old Open(name, O_RDWR|O_TRUNC|O_CREAT, 0666)
This CL includes a gofix module and full code updates: all.bash passes.
(There may be a few comments I missed.)
The interesting packages are:
gofix
os
Everything else is automatically generated except for hand tweaks to:
src/pkg/io/ioutil/ioutil.go
src/pkg/io/ioutil/tempfile.go
src/pkg/crypto/tls/generate_cert.go
src/cmd/goyacc/goyacc.go
src/cmd/goyacc/units.y
R=golang-dev, bradfitzwork, rsc, r2
CC=golang-dev
https://golang.org/cl/4357052
Change M-x gofmt to display errors in a new buffer instead of
clobbering the current buffer.
Add gofmt-before-save, which runs gofmt when in go-mode. This
can be used with before-save-hook. Add to your .emacs:
(add-hook 'before-save-hook 'gofmt-before-save)
R=rsc, aclements, amdragon
CC=golang-dev
https://golang.org/cl/4276059
* 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
In line with other functions such as Fprintf, put the
thing to be written first.
Apologies for the breakages this is sure to cause.
R=rsc, gri, adg, eds, r2, aam
CC=golang-dev
https://golang.org/cl/4169042
This aligns the naming scheme with the testing package and
also lets govet work on more logging calls.
R=rsc
CC=golang-dev
https://golang.org/cl/4001048
This change fixes the import plugin so that the
defined commands are available when opening a new
Go buffer from within Vim itself.
R=adg, rsc
CC=golang-dev
https://golang.org/cl/3998053
Forcing the synchronization of 500 lines is both slower and
less precise than searching for a known sync point.
Unfortunately, though, the way to synchronize correctly is
using the grouphere instruction, which has a bug.
I've already proposed the fix to Vim, so future releases
should have this working. We can continue using the 500 lines
syncing for now.
This change just documents the proper way to sync.
R=adg, dsymonds
CC=golang-dev
https://golang.org/cl/4029047
New ftplugin adds Import and Drop commands for Go buffers
in Vim. These commands ensure that the provided package is
imported (or not imported) in the current Go buffer, using
proper style and ordering, without moving the cursor.
E.g.
:Import strings
:ImportAs . strings
:Drop strings
Two mappings are also introduced to help with the fmt package:
\f => :Import fmt
\F => :Drop fmt
R=adg
CC=golang-dev
https://golang.org/cl/4009043
#pragma dynexport is no longer needed for
this use of cgo, since the gcc and gc code are
now linked together into the same binary.
It may still be necessary later.
On the Mac, you cannot use the GOT to resolve
symbols that exist in the current binary, so 6l and 8l
translate the GOT-loading mov instructions into lea
instructions.
On ELF systems, we could use the GOT for those
symbols, but for consistency 6l and 8l apply the
same translation.
The translation is sketchy in the extreme
(depending on the relocation being in a mov
instruction) but it verifies that the instruction
is a mov before rewriting it to lea.
Also makes typedefs global across files.
Fixes#1335.
Fixes#1345.
R=iant, r
CC=golang-dev
https://golang.org/cl/3650042
Clean up an error message and error exit too.
Insert blank line after "DO NOT EDIT" comment
to keep it from being a doc comment.
Fixes#1213.
Fixes#1222.
R=r
CC=golang-dev
https://golang.org/cl/3608042
* Add documentation about array arguments. Fixes issue 1125.
* Do not interpret x, y := z, w as special errno form. Fixes issue 952.
* Fix nested Go calls (brainman). Fixes issue 907.
R=r
CC=golang-dev
https://golang.org/cl/2214044
