Missed a case for variadic functions with too few arguments.
The code passes, and with the right error, but might as well record the test case.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/5732050
The recent addition of automatic function invocation generated
some troublesome ambiguities. Restore the previous behavior
and compensate by providing a "call" builtin to make it easy to
do what the automatic invocation did, but in a clear and explicit
manner.
Fixes#3140.
At least for now.
R=golang-dev, dsymonds, r
CC=golang-dev
https://golang.org/cl/5720065
I tried before to make relative imports work by simply
invoking the compiler in the right directory, so that
an import of ./foo could be resolved by ./foo.a.
This required creating a separate tree of package binaries
that included the full path to the source directory, so that
/home/gopher/bar.go would be compiled in
tmpdir/work/local/home/gopher and perhaps find
a ./foo.a in that directory.
This model breaks on Windows because : appears in path
names but cannot be used in subdirectory names, and I
missed one or two places where it needed to be removed.
The model breaks more fundamentally when compiling
a test of a package that lives outside the Go path, because
we effectively use a ./ import in the generated testmain,
but there we want to be able to resolve the ./ import
of the test package to one directory and all the other ./
imports to a different directory. Piggybacking on the compiler's
current working directory is then no longer possible.
Instead, introduce a new compiler option -D prefix that
makes the compiler turn a ./ import into prefix+that,
so that import "./foo" with -D a/b/c turns into import
"a/b/c/foo". Then we can invent a package hierarchy
"_/" with subdirectories named for file system paths:
import "./foo" in the directory /home/gopher becomes
import "_/home/gopher/foo", and since that final path
is just an ordinary import now, all the ordinary processing
works, without special cases.
We will have to change the name of the hierarchy if we
ever decide to introduce a standard package with import
path "_", but that seems unlikely, and the detail is known
only in temporary packages that get thrown away at the
end of a build.
Fixes#3169.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5732045
Except for the tests, this is mostly deleting code:
- removed several exprListModes:
blankStart: easily done explicitly, and trailing blanks
are cleaned up by the trimmer post-pass
blankEnd: never used
commaSep: all exprLists calls had this set
- added test cases for multi-line returns
(for a later fix of issue 1207)
- no formatting changes
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/5672062
Set dagger looks very much like t in some fonts, so superscript it.
os/signal is no longer in exp.
R=golang-dev, adg
CC=golang-dev
https://golang.org/cl/5720049
Fixes a problem Rob is having with goprotobuf.
Cannot add a test because the same case is more broken
when using ./ imports. That still needs to be fixed,
and is one aspect of issue 3169.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5725043
Also remove useless "install" argument to pkgpath now that go/build
defines package install locations.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/5714059
Build environments will often define stock LDFLAGS
that are not compatible with the gc ld, causing
non-obvious failures midway through the build.
R=golang-dev, rsc, minux.ma, rsc
CC=golang-dev
https://golang.org/cl/5724044
Also change Wait to say "exit" instead of "exit or stop".
I notice that Pid is not implemented on all systems.
Should we fix that?
Fixes#3138.
R=golang-dev, alex.brainman, r
CC=golang-dev
https://golang.org/cl/5710056
Presumably something about the very large go/build
doc comment breaks the build constraint parser in
cmd/dist. I don't feel like debugging C code right now,
so move it into its own file. If cmd/dist decides doc.go
is not part of the package, it will still build correctly.
R=golang-dev
TBR=golang-dev
CC=golang-dev
https://golang.org/cl/5722043
- Define what it means for two identifiers to be unique.
- The current spec is incorrect about exported
identifiers: for instance, it excluded fields
of non-exported types of exported variables
from being exported. It is easier to leave
the detailed specification away and let the
rest of the spec govern access of exported
identifiers.
- The current spec is incorrect about qualified
identifiers: It simply required that an identifier
be exported to be valid in a qualified identifier.
However, qualified identifiers can only access
exported identifiers declared in the package
block of the imported package.
Fixes#1551.
R=r, rsc, iant, ken
CC=golang-dev
https://golang.org/cl/5711043
