Skip to content

G
golang
Switch branch/tag
  1. 01 Aug, 2018 3 commits
    • Russ Cox's avatar
      cmd/go: change list -compiled to populate new CompiledGoFiles list · 53859e57
      Russ Cox authored 
      CL 108156 added -cgo during the Go 1.11 cycle.
To avoid adding a new field to Package, it redefined the
meaning of the CgoFiles list to be the cgo output instead
of the cgo input.

This was awkward in the go command itself, since the meaning
of the list changed midway through the build.

But, worse, it is awkward to users of go list.
When gathering information about a tree of packages,
we may want the names of both the cgo inputs and the cgo outputs
(golang.org/x/tools/go/packages does, it turns out),
or when combined with -deps (CL 107776),
we may only care about one list or the other depending
on whether the package was requested explicitly or is
being returned as a dependency.

Also, it's not general enough. SWIGFiles turn into cgo files
and then end up in the list too. And maybe there will be others
in the future. What clients really want is the list of files that
are presented to the go compiler, so that they can parse
and type-check them as if they were the compiler instead.

Eliminate all this awkwardness by dropping -cgo and adding
a new -compiled that populates a new CompiledGoFiles list.

Change-Id: I5f152da17cfb2692eedde61721d01ec13067c57d
Reviewed-on: https://go-review.googlesource.com/126695
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: 's avatarMichael Matloob <matloob@golang.org>
Reviewed-by: 's avatarBryan C. Mills <bcmills@google.com>
      53859e57
    • Russ Cox's avatar
      cmd/go: split go mod into multiple subcommands · 6121987a
      Russ Cox authored 
      The current "go mod" command does too many things.
The design is unclear.

It looks like "everything you might want to do with modules"
which causes people to think all module operations go through
"go mod", which is the opposite of the seamless integration we're
going for. In particular too many people think "go mod -require"
and "go get" are the same.

It does make sense to put the module-specific functionality
under "go mod", but not as flags. Instead, split "go mod" into
multiple subcommands:

	go mod edit   # old go mod -require ...
	go mod fix    # old go mod -fix
	go mod graph  # old go mod -graph
	go mod init   # old go mod -init
	go mod tidy   # old go mod -sync
	go mod vendor # old go mod -vendor
	go mod verify # old go mod -verify

Splitting out the individual commands makes both the docs
and the implementations dramatically easier to read.
It simplifies the command lines
(go mod -init -module m is now 'go mod init m')
and allows command-specific flags.

We've avoided subcommands in the go command to date, and we
should continue to avoid adding them unless it really makes
the experience significantly better. In this case, it does.

Creating subcommands required some changes in the core
command-parsing and help logic to generalize from one
level to multiple levels.

As part of having "go mod init" be a separate command,
this CL changes the failure behavior during module initialization
to be delayed until modules are actually needed.
Initialization can still happen early, but the base.Fatalf
is delayed until something needs to use modules.
This fixes a bunch of commands like 'go env' that were
unhelpfully failing with GO111MODULE=on when not in a
module directory.

Fixes #26432.
Fixes #26581.
Fixes #26596.
Fixes #26639.

Change-Id: I868db0babe8c288e8af684b29d4a5ae4825d6407
Reviewed-on: https://go-review.googlesource.com/126655
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarBryan C. Mills <bcmills@google.com>
      6121987a
    • Russ Cox's avatar
      cmd/go: add 'go version' statement in go.mod · 16962faf
      Russ Cox authored 
      We aren't planning to use this or advertise it much yet,
but having support for it now will make it easier to start
using in the future - older go commands will understand
what 'go 1.20' means and that they don't have go 1.20.

Fixes #23969.

Change-Id: I729130b2690d3c0b794b49201526b53de5093c45
Reviewed-on: https://go-review.googlesource.com/125940
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarBryan C. Mills <bcmills@google.com>
      16962faf
  3. 31 Jul, 2018 20 commits
  5. 30 Jul, 2018 3 commits
  7. 29 Jul, 2018 3 commits
  9. 28 Jul, 2018 9 commits
  11. 27 Jul, 2018 2 commits
    • Craig Citro's avatar
      net/http: document Transport.Proxy's https support · 8450fd96
      Craig Citro authored 
      The net/http module added support for HTTPS proxies in CL 68550, but the
Transport.Proxy docstring was never updated to reflect this. This (doc-only)
update adds "https" to the list of supported schemes.

Change-Id: I0570fcdae8232bb42d52c4dd739dd09ee8dfd612
Reviewed-on: https://go-review.googlesource.com/126495Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      8450fd96
    • Ian Lance Taylor's avatar
      syscall: support Faccessat flags argument · d9705190
      Ian Lance Taylor authored 
      The Linux kernel faccessat system call does not take a flags parameter.
The flag parameter to the C library faccessat function is implemented in C.
The syscall.Faccessat function takes a flags parameter. In older releases
we have passed the flags parameter to the kernel, which ignored it.
In CL 120015 we started returning an error if any flags were set.
That seems clearly better than ignoring them, but it turns out that some
code was using the flags. The code was previously subtly broken.
Now it is obviously broken. That is better, but we can do better still:
we can implement the flags as the C library does. That is what this CL does.

Change-Id: I259bd6f240c3951e939b81c3032dead3d9c567b4
Reviewed-on: https://go-review.googlesource.com/126415
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      d9705190