We only guarantee that the main goroutine runs on the
main OS thread for initialization. Programs that wish to
preserve that property for main.main can call runtime.LockOSThread.
This is what programs used to do before we unleashed
goroutines during init, so it is both a simple fix and keeps
existing programs working.
R=iant, r, dave, dvyukov
CC=golang-dev
https://golang.org/cl/5309070
I found these by adding a check to govet, but the check
produces far too many false positives to be useful.
Even so, these few seem worth cleaning up.
R=golang-dev, bradfitz, iant
CC=golang-dev
https://golang.org/cl/5311067
This is true of the existing implementations, and I think
it is an important property to guarantee.
R=golang-dev, r, borman, r
CC=golang-dev
https://golang.org/cl/5321058
goinstall has built in support for a few common code hosting sites. The
identification of which vcs tool should be used was based purely on a
regex match against the provided import path. The problem with this
approach is that it requires distinct import paths for different vcs
tools on the same site.
Since bitbucket has recently starting hosting Git repositories under the
same bitbucket.org/user/project scheme as it already hosts Mercurial
repositories, now would seem a good time to take a more flexible
approach.
We still match the import path against a list of regexes, but now the
match is purely to distinguish the different hosting sites. Once the
site is identified, the specified function is called with the repo and
path matched out of the import string. This function is responsible for
creating the vcsMatch structure that tells us what we need to download
the code.
For github and launchpad, only one vcs tool is currently supported, so
these functions can simply return a vcsMatch structure. For googlecode,
we retain the behaviour of determing the vcs from the import path - but
now it is done by the function instead of the regex. For bitbucket, we
use api.bitbucket.org to find out what sort of repository the specified
import path corresponds to - and then construct the appropriate vcsMatch
structure.
R=golang-dev, adg
CC=golang-dev, rsc
https://golang.org/cl/5306069
Change the name of cas() in cc to newcase() to avoid a NIX conflict.
cas() is used in cc to create a new Case struct. There is a name
conflict in that cas() is a commonly-used
name for compare and swap. Since cas() is only used internally
in the compiler in 3 places, change the name to avoid a wider
conflict with the NIX runtime. This issue might well come up on
other OSes in the future anyway, as the name is fairly common.
R=rsc
CC=golang-dev
https://golang.org/cl/5294071
Small change to go/ast, go/parser, go/printer so that
gofix can delete the blank line left from deleting an import.
R=golang-dev, bradfitz, adg
CC=golang-dev
https://golang.org/cl/5321046
Although there's still no concrete security reason not to use 3, I
think Bleichenbacher has convinced me that it's a useful defense and
it's what everyone else does.
R=bradfitz, rsc
CC=golang-dev
https://golang.org/cl/5307060
Nothing terribly interesting here. (!)
Since the public APIs are all in terms of UTF-8,
the changes are all internal only.
R=mpvl, gri, r
CC=golang-dev
https://golang.org/cl/5309042
API question: is a scanner token an int or a rune?
Since the rune is the common case and the token values
are the special (negative) case, I chose rune. But it could
easily go the other way.
R=gri
CC=golang-dev
https://golang.org/cl/5301049
need a clean base from weekly.2011-10-25 for rune change
««« original CL description
http: remove Connection header in ReverseProxy
Fixes#2342
R=golang-dev, adg
CC=golang-dev
https://golang.org/cl/5302057
»»»
R=rsc
CC=golang-dev
https://golang.org/cl/5294068
